Skip to content

route: custom cluster specifier plugin support#20151

Merged
mattklein123 merged 21 commits intoenvoyproxy:mainfrom
wbpcode:cluster_provider
Apr 26, 2022
Merged

route: custom cluster specifier plugin support#20151
mattklein123 merged 21 commits intoenvoyproxy:mainfrom
wbpcode:cluster_provider

Conversation

@wbpcode
Copy link
Copy Markdown
Member

@wbpcode wbpcode commented Mar 1, 2022

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.

Signed-off-by: wbpcode <wbphub@live.com>
@repokitteh-read-only
Copy link
Copy Markdown

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @lizan
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #20151 was opened by wbpcode.

see: more, trace.

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 1, 2022

First commit is pushed for quick API and design review.

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 1, 2022

cc @tyxia cc @alyssawilk

Signed-off-by: wbpcode <wbphub@live.com>
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 4, 2022

@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?

Comment thread api/envoy/config/route/v3/route_components.proto Outdated
@RyanTheOptimist
Copy link
Copy Markdown
Contributor

/wait

@lizan
Copy link
Copy Markdown
Member

lizan commented Mar 11, 2022

/lgtm api

Comment thread api/envoy/config/route/v3/route.proto Outdated
// 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;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API versioning policy being updated in #20347.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get it. May we need some new tags for fields that envoy not implemented but other proxies used.

Comment thread api/envoy/config/route/v3/route_components.proto Outdated
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 20, 2022

/waiting

Waiting #20301 merged to avoid unnecessary conflict.

Copy link
Copy Markdown
Contributor

@markdroth markdroth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree with using the original type for clarity in this case.

Comment thread api/envoy/config/route/v3/route_components.proto Outdated
Signed-off-by: wbpcode <wbphub@live.com>
Comment thread api/envoy/config/route/v3/route.proto
Comment thread api/envoy/config/route/v3/route_components.proto
Comment thread api/envoy/config/route/v3/route_components.proto
Comment thread api/envoy/config/route/v3/route_components.proto Outdated
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 29, 2022

Sorry, I didn't follow that explanation. Let me try asking a more specific question: If we allow the plugins to be defined at the VirtualHost level so that they work with VHDS, what will not work?

In fact, RouteConfiguration's plugins are already worked (Although in the vhds case there are some issues, it always worked). But it's not friendly for the current users of cluster_header/weighted_clusters to migrate their configs. And it's not friendly for some control planes who have special abstraction for Route.

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 29, 2022

To be clear, I'm really not comfortable with defining the plugin in the individual route. I think that will badly confuse the semantics of the ClusterSpecifierPlugin, which are intended to allow the plugin instance to be stateful and to have that same state apply across multiple routes that are using the same plugin. I think that in order to consider doing that, we need some justification as to why it's worth introducing that problem, and at the moment, it's not clear to me that we have such a justification.

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.

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Mar 29, 2022

The API I expected only has two targets:

  • extendable.
  • easy to replace current cluster_header/weighted_clusters.

It's hard to convince users to migrate their current route-level configs to RouteConfiguration and ref them in the Route. But it would be possible to convince users to move their route-level configs to a route-level Any wrapper.

So that we can finally smoothly deprecate the cluster_header/weighted_clusters.

Signed-off-by: wbpcode <wbphub@live.com>
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 21, 2022

Sorry for the late update. I opened too much threads at same time. 😞

wbpcode added 2 commits April 21, 2022 16:34
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 22, 2022

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #20151 (comment) was created by @wbpcode.

see: more, trace.

wbpcode added 4 commits April 22, 2022 12:27
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get it. Thanks for calling it out.

To my surprise, I thought I had done all the name substitutions. I will check it again.

wbpcode added 2 commits April 23, 2022 10:39
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
@wbpcode wbpcode changed the title route: custom cluster plugin support route: custom cluster specifier plugin support Apr 23, 2022
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 24, 2022

Now, these should be no any 'cluster provider'. Could you take a look again? 😄 cc @markdroth

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 24, 2022

And it ready for an code review also. Could you take a look when you have free time? cc @mattklein123

@markdroth
Copy link
Copy Markdown
Contributor

/lgtm api

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread envoy/router/cluster_specifier_plugin.h Outdated
Comment thread source/common/router/config_impl.cc Outdated
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 26, 2022

It would be nice to add a small integration test that adds a test plugin to set a route? Thank you!

Get it.

@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 26, 2022

/wait

wbpcode added 2 commits April 26, 2022 04:01
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
@wbpcode
Copy link
Copy Markdown
Member Author

wbpcode commented Apr 26, 2022

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #20151 (comment) was created by @wbpcode.

see: more, trace.

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@mattklein123 mattklein123 merged commit 07e414c into envoyproxy:main Apr 26, 2022
ravenblackx pushed a commit to ravenblackx/envoy that referenced this pull request Jun 8, 2022
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants