udpa: plumb udpa:// resource names/locators. #11810
Conversation
These are currently set as [#not-implemented-hide:]. There should be enough plumbing here to start implementing the first roadmap steps in envoyproxy#11264, i.e. some simple delta discovery flows with core LDS/CDS/RDS/EDS/SDS. I've punted on VHDS and SRDS until later, as these will require special case mapping of their resource keys into context parameters. Risk level: Low (Unused API changes). Testing: Built docs and proto_format.sh. Part of envoyproxy#11264. Signed-off-by: Harvey Tuch <htuch@google.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s), but failed to run 2 pipeline(s). |
Signed-off-by: Harvey Tuch <htuch@google.com>
| // Resource locator for EDS. This is mutually exclusive to *service_name*. | ||
| // [#not-implemented-hide:] | ||
| udpa.core.v1.ResourceLocator eds_resource_locator = 3 | ||
| [(udpa.annotations.field_migrate).oneof_promotion = "name_specifier"]; |
There was a problem hiding this comment.
Don't we want this field to replace both the service_name field and the eds_config field? In other words, I think we want either this new field or both eds_config and service_name.
Maybe the right thing to do here is to leave the EdsClusterConfig message alone and move this new field into a top-level field in the Cluster message. Then the oneof can contain this new field and the EdsClusterConfig field.
There was a problem hiding this comment.
So, as per the resolution algorithm in the bootstrap, I think it's fine to have "peer config sources". This get checked first, then the bootstrap. It provides a more gradual path to adoption for folks who don't already provide config sources for everything in bootstrap.
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Show resolved
Hide resolved
Signed-off-by: Harvey Tuch <htuch@google.com>
|
@mattklein123 any additional comments or changes you'd like to see happen? |
These are currently set as [#not-implemented-hide:]. There should be enough plumbing here to start
implementing the first roadmap steps in #11264, i.e. some simple delta discovery flows with core
LDS/CDS/RDS/EDS/SDS.
I've punted on VHDS and SRDS until later, as these will require special case mapping of their
resource keys into context parameters.
Risk level: Low (Unused API changes).
Testing: Built docs and proto_format.sh.
Part of #11264.
Signed-off-by: Harvey Tuch htuch@google.com