Skip to content

Conversation

finnegancarroll
Copy link
Contributor

@finnegancarroll finnegancarroll commented Sep 15, 2025

Description

Adds a GrpcServiceFactory interface as an extension point for other plugins to implement. GrpcServiceFactory provides an interface for wrapping a predefined io.grpc.BindableService which can be registered on the gRPC transport. Enabling plugins to provide their own service definitions opens the door for supporting pre-defined service schemas within the gRPC transport (such as Flight or OTEL) proto types, as well as custom hand rolled services which do not mirror the REST API and are not tracked by the API spec.

Related Issues

Resolves #19025

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@github-actions github-actions bot added enhancement Enhancement or improvement to existing feature or request Plugins labels Sep 15, 2025
@github-actions
Copy link
Contributor

✅ Gradle check result for 813ede2: SUCCESS

@codecov
Copy link

codecov bot commented Sep 15, 2025

Codecov Report

❌ Patch coverage is 93.61702% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.06%. Comparing base (39b7a59) to head (723b5f6).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
...java/org/opensearch/transport/grpc/GrpcPlugin.java 93.02% 0 Missing and 3 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main   #19304      +/-   ##
============================================
+ Coverage     73.00%   73.06%   +0.06%     
- Complexity    70534    70605      +71     
============================================
  Files          5719     5720       +1     
  Lines        323260   323292      +32     
  Branches      46816    46819       +3     
============================================
+ Hits         235993   236226     +233     
+ Misses        68224    68004     -220     
- Partials      19043    19062      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@finnegancarroll
Copy link
Contributor Author

finnegancarroll commented Sep 18, 2025

Hi @andrross @karenyrx can I get your thoughts on this approach?

Intentionally not including GrpcServiceFactory in the SPI as BindableService needs io.grpc:grpc-core. Wondering if a second SPI is best here to avoid leaking org.opensearch:protobufs into plugins which may not ever use it.

@github-actions
Copy link
Contributor

❌ Gradle check result for 280fd95: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@finnegancarroll finnegancarroll marked this pull request as ready for review September 23, 2025 01:08
@finnegancarroll finnegancarroll requested a review from a team as a code owner September 23, 2025 01:08
@github-actions
Copy link
Contributor

❌ Gradle check result for bf90052: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@andrross
Copy link
Member

Intentionally not including GrpcServiceFactory in the SPI as BindableService needs io.grpc:grpc-core. Wondering if a second SPI is best here to avoid leaking org.opensearch:protobufs into plugins which may not ever use it.

@finnegancarroll I see you created a second SPI. Isn't BindableService a part of grpc-api, which only has dependencies on findbugs and errorprone annotations? That seems pretty lightweight and would be okay in a single SPI. What am I missing?

@finnegancarroll
Copy link
Contributor Author

@finnegancarroll I see you created a second SPI. Isn't BindableService a part of grpc-api, which only has dependencies on findbugs and errorprone annotations? That seems pretty lightweight and would be okay in a single SPI. What am I missing?

Hi @andrross, the main reason to separate this SPI was the guava runtime dependency. Guava is runtime only in the main module as well and plugins such as KNN which only want the protobuf definitions run into version and subsequent runtime issues within the plugin test infrastructure. Here is the workaround for the original KNN PR:
https://github.com/opensearch-project/k-NN/pull/2817/files#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7R343-R351

@andrross
Copy link
Member

@finnegancarroll I see you created a second SPI. Isn't BindableService a part of grpc-api, which only has dependencies on findbugs and errorprone annotations? That seems pretty lightweight and would be okay in a single SPI. What am I missing?

Hi @andrross, the main reason to separate this SPI was the guava runtime dependency. Guava is runtime only in the main module as well and plugins such as KNN which only want the protobuf definitions run into version and subsequent runtime issues within the plugin test infrastructure. Here is the workaround for the original KNN PR: opensearch-project/k-NN#2817 (files)

@finnegancarroll Does the new SPI really need a Guava runtime dependency? I guess I was thinking this new code would only require adding the grpc-api dependency, and that it could just be added to the existing SPI which would stay pretty lightweight. Does that not work?

@finnegancarroll
Copy link
Contributor Author

@finnegancarroll Does the new SPI really need a Guava runtime dependency? I guess I was thinking this new code would only require adding the grpc-api dependency, and that it could just be added to the existing SPI which would stay pretty lightweight. Does that not work?

Hi @andrross , doing some experimenting and guava can be excluded here and listed under ignoreMissingClasses in third party audit. The result would be guava is a unlisted runtime dependency however this seems relatively safe since it will probably never be the case that plugins using this interface will attempt to implement a BindableService from scratch and will almost certainly already have guava at runtime through dependencies they use to generate their BindableService implementations.

One other consideration I think is extending this SPI to include other grpc-api definitions in the future. What comes to mind is ServerInterceptor which is much more likely to be directly implemented, however i'm not sure this changes much as most plugins already have guava at runtime so it's difficult to imagine this being an issue still.

What do you think? Is it preferable to stick with the single SPI implementation and exclude guava or list it explicitly in a separate SPI?

@github-actions
Copy link
Contributor

❌ Gradle check result for 28b757b: null

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@finnegancarroll
Copy link
Contributor Author

Per offline convo with @andrross the second SPI is not needed as guava which is a transitive runtime dependency of grpc-api will of course always be present since implemented services are executed within the gRPC transport module. Removed the duplicate SPI and updated the readme to include GrpcServiceFactory endpoint.

@github-actions
Copy link
Contributor

❌ Gradle check result for 28b757b: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

✅ Gradle check result for 28b757b: SUCCESS

@github-actions
Copy link
Contributor

❌ Gradle check result for 17594d9: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

✅ Gradle check result for f56a7c9: SUCCESS

@finnegancarroll finnegancarroll force-pushed the grpc-plug-services branch 3 times, most recently from 2ecf895 to f2d4101 Compare October 7, 2025 21:23
@github-actions
Copy link
Contributor

github-actions bot commented Oct 7, 2025

✅ Gradle check result for bd4e04f: SUCCESS

@finnegancarroll
Copy link
Contributor Author

finnegancarroll commented Oct 7, 2025

@andrross @mch2 can you take another look at this when you have a chance? Thanks!

@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2025

✅ Gradle check result for 723b5f6: SUCCESS

@finnegancarroll finnegancarroll force-pushed the grpc-plug-services branch 2 times, most recently from 69f480b to c177d49 Compare October 21, 2025 17:19
Leverages the extensible plugin framework enabling plugins to provide
`BindableService` implementations which will registered on the grpc-transport.

Signed-off-by: Finn Carroll <[email protected]>
Signed-off-by: Finn Carroll <[email protected]>
@github-actions
Copy link
Contributor

❌ Gradle check result for 6c7bca0: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@finnegancarroll
Copy link
Contributor Author

finnegancarroll commented Oct 21, 2025

* What went wrong:
Execution failed for task ':distribution:bwc:minor:buildBwcLinuxTar'.
> Building 3.3.0 didn't generate expected file /var/jenkins/workspace/gradle-check/search/distribution/bwc/minor/build/bwc/checkout-3.3/distribution/archives/linux-tar/build/distributions/opensearch-min-3.3.0-SNAPSHOT-linux-x64.tar.gz

Seems related to recent 3.3.1 minor version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Enhancement or improvement to existing feature or request Plugins

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature Request] Allow plugins to inject predefined services into gRPC transport module

4 participants