Support multiple ADS configuration to allow distinct control-planes to serve parts of the configuration

[valerian-roche]

• Commit Message: Support multiple ADS configuration to allow distinct control-planes to serve parts of the configuration
• Additional Description:
  In order to allow multiplexing of watches for distinct control-planes from the main ADS provider, add support for addtional control-plane instances to be considered as ADS providers. Those instances can be referenced within the configuration of other config_sources through a new ads: instance: field. By default ADS behavior is unchanged.
  Those additional instances are configured in the initial bootstrapping configuration and inherit the same constraints (e.g. only depending on primary clusters). Those could potentially be relaxed to allow depending on secondary clusters loaded through the primary ADS instance, but this would make the change much more complex for unclear benefit.
• Risk Level: medium. No functional change without opt-in.
• Testing:
• Docs Changes:
• Release Notes:
  • Support additional ADS instances, allowing multiplexing resource watches to distinct control-planes from the original ones.
• Fixes Support multiple ADS configuration to allow distinct control-planes to serve parts of the configuration #35483
• API Considerations

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #35485 was opened by valerian-roche.

see: more, trace.

[repokitteh-read-only]

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

🐱

Caused by: #35485 was opened by valerian-roche.

see: more, trace.

[htuch]

Can we adapt the authority model for selecting ADS server described at https://github.com/cncf/xds/blob/main/proposals/TP1-xds-transport-next.md. I think this is where @envoyproxy/api-shepherds would prefer to see this support head, tagged @adisuissa and @markdroth as reviewers.

[valerian-roche]

Can we adapt the authority model for selecting ADS server described at https://github.com/cncf/xds/blob/main/proposals/TP1-xds-transport-next.md. I think this is where @envoyproxy/api-shepherds would prefer to see this support head, tagged @adisuissa and @markdroth as reviewers.

We are discussing this on envoy slack. I'd like to not merge the xdstp migration with this, as in my opinion the envoy interface allows this (small changes in this PR) while keeping consistency, and the full xdstp migration is far more involved on users (major potential impact on control-plane behaviors, for instance to guarantee resource unicity).
I am nevertheless looking at being as consistent as possible with the new model, to allow a transparent (as much as possible) transition later on (e.g. could the additional_ads_configs be directly reused through xdstp)

[markdroth]

I don't think this is the right approach. See #13951 for the roadmap that I think we want to follow here.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[github-actions]

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!