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.

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

Have the ability to have different TypeUrl from Discovery Request vs Discovery Response #303

Closed
lita opened this issue Jun 1, 2020 · 9 comments
Labels

Comments

@lita
Copy link

lita commented Jun 1, 2020

Currently, go-control-plane doesn't provide a way for us to send v3 configuration through the v2 protocol, as supported by envoy for a migration.

For Fetch, it always sets the DiscoveryRequest TypeUrl.

For Streaming, it always uses the v2 resources when using the v2/cache.go module.

In order to support the v2->v3 migration, we will need to add functionality here to allow the TypeUrl to be changed. It's not clear to me if the passthrough work will handle this or not, since it is still using the request TypeUrl.

@jyotimahapatra
Copy link
Contributor

jyotimahapatra commented Jun 1, 2020

I don't think envoy accepts v3 response in return for a v2 request or vice versa, based on the observation here.

@lita
Copy link
Author

lita commented Jun 1, 2020

After talking with @jessicayuen, it looks like the Passthrough struct takes the raw discovery proto.

@lita
Copy link
Author

lita commented Jun 1, 2020

@jyotima I believe Envoy added code to do the v2 -> v3 conversion since the last time you did that test.

@jyotimahapatra
Copy link
Contributor

jyotimahapatra commented Jun 1, 2020

@lita That's possible, but i saw that the issue is still open and not linked to any PR. Worth retesting it again to check if this is solved.

@jyotimahapatra
Copy link
Contributor

In order to perform migration, go-control-plane enables registering the v3 endpoint. Although the cache management will require more code until envoyproxy/envoy#10776 is done.

@lita
Copy link
Author

lita commented Jun 1, 2020

@jyotimahapatra
Copy link
Contributor

jyotimahapatra commented Jun 1, 2020

That is true. The grpc endpoints are chosen based on type_url , based on resource_api_version .
The transport_api_version is only really used here to scrub deprecated fields.

I feel there is not much correlation between typeurl and transport version.
A v2 resource version request requires a v2 resource response and v3 resource needs a v3 resource version in response. In other words, control plane needs to register both v2 and v3 grpc endpoints for different resource versions.

@github-actions
Copy link

github-actions bot commented Apr 6, 2021

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Apr 6, 2021
@github-actions
Copy link

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants