Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

xDS client endpoint discovery #8421

Closed
htuch opened this issue Sep 27, 2019 · 11 comments
Closed

xDS client endpoint discovery #8421

htuch opened this issue Sep 27, 2019 · 11 comments
Assignees
@htuch
Labels
api/v3 Major version release @ end of Q3 2019 no stalebot Disables stalebot from closing an issue
Milestone
1.13.0

Comments

@htuch
Copy link
Member

htuch commented Sep 27, 2019

Current plan-of-record is to have ConfigSource indicate the version (and hence service endpoints), allowing the xDS client to select the correct URLs and translators to use on configuration ingestion.
@htuch htuch added help wanted Needs help! api/v3 Major version release @ end of Q3 2019 labels Sep 27, 2019
@htuch htuch added this to the 1.12.0 milestone Sep 27, 2019
@htuch htuch modified the milestones: 1.12.0, 1.13.0 Oct 16, 2019
@Shikugawa
Copy link
Member

@htuch In my recognition, It enables to update xDS client config like eds_config dynamically. For example, update subscribed xDS server(xDS v1) when updating config signal was injected to them and disconnect. after that, establish connection with new xDS server(xDS v2). Please point out my opinion if this is wrong.

@htuch
Copy link
Member Author

htuch commented Dec 18, 2019

@Shikugawa I'm not anticipating highly dynamic behavior here; instead we should just expect the more recent management servers and bootstraps are configured to deliver xDS that uses the new config source type, while Envoy retains the ability to still speak to older xDS servers if needed.

@Shikugawa
Copy link
Member

@htuch So to speak, I think that we need to allow multiple ApiConfigSource on single ConfigSource.

@htuch
Copy link
Member Author

htuch commented Dec 19, 2019

@Shikugawa I think eventually we want to support clients able to try one endpoint at version X and fallback, but for now we can support just a well specified endpoint / config source, at least for 1.13.0

This was referenced Dec 24, 2019
Closed
Merged
htuch pushed a commit that referenced this issue Dec 30, 2019
@Shikugawa @htuch
api: xDS API version specifier (#9468)
e3717b5 
It enables to specify API versioning for xDS for #8421, allow to write like this config

eds_cluster_config:
    eds_config:
       version: V2 
       api_config_source:
          api_type: GRPC
	  grpc_services:
            envoy_grpc:
               cluster_name: eds_cluster

Risk Level: Low
Testing: unit test(maybe it is needed to add integration test)

Signed-off-by: shikugawa <rei@tetrate.io>
prakhag1 pushed a commit to prakhag1/envoy that referenced this issue Jan 3, 2020
@Shikugawa @prakhag1
api: xDS API version specifier (envoyproxy#9468)
dcc1814 
It enables to specify API versioning for xDS for envoyproxy#8421, allow to write like this config

eds_cluster_config:
    eds_config:
       version: V2 
       api_config_source:
          api_type: GRPC
	  grpc_services:
            envoy_grpc:
               cluster_name: eds_cluster

Risk Level: Low
Testing: unit test(maybe it is needed to add integration test)

Signed-off-by: shikugawa <rei@tetrate.io>
Signed-off-by: Prakhar <prakhar_au@yahoo.com>
@htuch htuch removed the help wanted Needs help! label Jan 7, 2020
@htuch htuch self-assigned this Jan 7, 2020
@mattklein123 mattklein123 added the no stalebot Disables stalebot from closing an issue label Jan 7, 2020
@htuch
Copy link
Member Author

htuch commented Jan 8, 2020

Fixed in #9526

@htuch htuch closed this as completed Jan 8, 2020
@htuch htuch reopened this Apr 14, 2020
@htuch
Copy link
Member Author

htuch commented Apr 14, 2020

I'm reopening this issue as there is some demand for the ability for (in simple cases) to be able to do rollouts using a mechanism that does fallback as described in #8421 (comment).

@htuch
Copy link
Member Author

htuch commented Apr 14, 2020

CC @Shikugawa @mattklein123 @snowp @lita @jyotima

@htuch
Copy link
Member Author

htuch commented Apr 14, 2020

See also #10776 as an alternative approach to rollouts.

@lita
Copy link

lita commented Apr 14, 2020 •
edited
Loading

This would be great, as specifying the bootstrap file and rolling that out is painful and risky.

@mattklein123
Copy link
Member

FWIW I prefer #10776 over this. IMO it does the same thing and is easier to reason about with less config needed.

@howardjohn howardjohn mentioned this issue Apr 16, 2020
Closed
@htuch htuch mentioned this issue Apr 21, 2020
Merged
@htuch
Copy link
Member Author

htuch commented Nov 13, 2020

I think this is obsoleted by #10776.

@htuch htuch closed this as completed Nov 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@htuch htuch

Labels
api/v3 Major version release @ end of Q3 2019 no stalebot Disables stalebot from closing an issue
Projects
None yet
Milestone
1.13.0
Development

No branches or pull requests
4 participants
@lita @mattklein123 @htuch @Shikugawa