[gRPC] Versioning strategy for opensearch-protobufs schema

[finnegancarroll]

Is your feature request related to a problem? Please describe

The protobuf schema which defines the API of the gRPC transport is still in flux and liable to introduce breaking changes before the first major version. To maintain compatibility OSB gRPC operations may need a strategy to disallow these operations on clusters which are not compatible. There are a few options for doing so.

Describe the solution you'd like

My preferred solution is to Include version guards in OSB workloads. OSB workloads are fetched on each run and can be updated to exclude a previous incompatible version when a breaking change is introduced to the protobuf schema and will be reflected by OSB in real time.

Describe alternatives you've considered

Alternative solutions could be:

1. Include compatibility matrix in OSB documentation which maps OSB version compatibility to OpenSearch versions for the purpose of the gRPC transport.
2. Include version guards in OSB directly, checking the version of OpenSearch and compatibility with the protobuf schema whenever we initialize a gRPC runner.

I am thinking version guards within OSB workloads offers additional benefits over these other options.

• Within OSB workloads we can determine compatibility for specific operations. For example even if there is a change in the protobuf schema for bulk request related to updating documents, this does not break compatibility for the Big5 workload grpc-index-append and so we can consider version guards on a case by case basis.
• As previously mentioned OSB workloads are updated by OSB on each run and so we do not have to wait for the next OSB release to fix the versioning requirements on a particular operation.
• Other version guards for API changes are included in OSB workloads, for newly introduced or fields modified over major versions. This solution best matches current conventions.

Additional context

No response

[andrross]

Catch All Triage - 1 2 3