route: custom cluster specifier plugin support#20151
route: custom cluster specifier plugin support#20151mattklein123 merged 21 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: wbpcode <wbphub@live.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
First commit is pushed for quick API and design review. |
|
cc @tyxia cc @alyssawilk |
|
@lizan Friendly ping. Hi, could you give a quick API review for this PR when you have free time, then we can push this work to the next step? |
|
/wait |
|
/lgtm api |
| // A list of cluster providers and their configurations which may be used by a | ||
| // :ref:`cluster provider name <envoy_v3_api_field_config.route.v3.RouteAction.cluster_provider_name>` | ||
| // within the route. All *name* fields in this list must be unique. | ||
| repeated core.v3.TypedExtensionConfig cluster_providers = 12; |
There was a problem hiding this comment.
This change is not okay. This will break a field that is actually being used by gRPC. Just because a field is not used in Envoy does not mean it's okay to change it.
Please revert these API changes.
There was a problem hiding this comment.
@markdroth So you implemented a hiden API of Envoy in the gRPC? While I think we can revert these API changes this time around, I don't think this is the right pattern. cc @envoyproxy/api-shepherds
There was a problem hiding this comment.
I think you may be misunderstanding the context of the xDS API. While this API did start as part of Envoy, these days it's actually moving toward being a general-purpose data plane API, where Envoy is only one of many clients. In fact, gRPC has xDS client implementations in 4 different languages. We do sometimes add new fields to the API that gRPC implements support for before Envoy does; when this happens, the field may still be tagged with a "not-implemented-hide" tag for the benefit of Envoy's auto-generated documentation, but that doesn't mean that it's not used by other clients and is okay to break.
That having been said, it looks to me like the API versioning policy does incorrectly say that the policy does not apply to fields tagged with "not-implemented-hide". I think that's out of date and needs to be changed, and I'll put together a PR to fix that.
In any case, speaking as one of the API shepherds, it is definitely not okay to break these fields, since we do absolutely have clients of this API that are using them. Please revert these changes.
There was a problem hiding this comment.
Get it. May we need some new tags for fields that envoy not implemented but other proxies used.
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
|
/waiting Waiting #20301 merged to avoid unnecessary conflict. |
markdroth
left a comment
There was a problem hiding this comment.
I'd like input from the other @envoyproxy/api-shepherds on this.
| string cluster_specifier_plugin = 37; | ||
|
|
||
| // Custom cluster provider configuration to use to determine the cluster for requests on this route. | ||
| core.v3.TypedExtensionConfig cluster_provider = 39 |
There was a problem hiding this comment.
The way this is structured, it looks like you're adding a new extension point instead of implementing the one that already exists in the API. I don't think we want two different ways of doing the same thing.
If we do wind up wanting a way to define the plugin on a per-route basis, then I think it should just be another way of instantiating a ClusterSpecifierPlugin. We should not define a separate extension type called ClusterProvider that does basically the same thing. In other words, it could be something like this:
ClusterSpecifierPlugin cluster_specifier_plugin_instance = 39;
There was a problem hiding this comment.
You are right. And I am waiting #20301 to be merged, then I will update this pr. Because maybe I need to move Cluster SpecifierPlugin to route_component.proto from route.proto.
There was a problem hiding this comment.
Yeah, I agree with using the original type for clarity in this case.
Signed-off-by: wbpcode <wbphub@live.com>
In fact, |
IMO, it will not break any semantics. The shared plugin has the shared states. And the route level plugin is shared by only one single route. It is just a special use case of shared plugin. And this should be a common design in the envoy API. A global shared config and a route level specified config. You can find some similar designs in the lua, rabc, etc. |
|
The API I expected only has two targets:
It's hard to convince users to migrate their current route-level configs to So that we can finally smoothly deprecate the cluster_header/weighted_clusters. |
|
Sorry for the late update. I opened too much threads at same time. 😞 |
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
| // :ref:`envoy_v3_api_field_config.route.v3.RouteConfiguration.cluster_specifier_plugins` | ||
| // in the | ||
| // :ref:`envoy_v3_api_field_config.core.v3.TypedExtensionConfig.name` field. | ||
| // Name of the cluster provider to use to determine the cluster for requests on this route. |
There was a problem hiding this comment.
This text still needs to be restored to the original wording. The original wording called this a "cluster specifier plugin", which is the correct term; the modified text says "cluster provider", which is not the term we're using here.
There was a problem hiding this comment.
Get it. Thanks for calling it out.
To my surprise, I thought I had done all the name substitutions. I will check it again.
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
|
Now, these should be no any 'cluster provider'. Could you take a look again? 😄 cc @markdroth |
|
And it ready for an code review also. Could you take a look when you have free time? cc @mattklein123 |
|
/lgtm api |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks LGTM with small comments. It would be nice to add a small integration test that adds a test plugin to set a route? Thank you!
/wait
Get it. |
|
/wait |
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode wbphub@live.com
Commit Message: route: custom cluster provider support
Additional Description:
Now, the cluster name, cluster header and weighted clusters are supported to get a target cluster of the route entry.
And this PR try to create extensible cluster providers for the route entry to support more flexible approaches to get the target cluster.
Ref #20060 for more info.
Risk Level: Low.
Testing: Wait.
Docs Changes: N/A.
Release Notes: Wait.
Platform Specific Features: N/A.