-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[envoy-15622] add generic XDS protobuf definitions #15760
Conversation
Hi @su225, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
907fa8c
to
45183a7
Compare
Can you provide some background context on this PR? Thank you. /wait |
api/envoy/admin/v3/config_dump.proto
Outdated
UpdateFailureState error_state = 6; | ||
} | ||
|
||
string type_url = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Matt and others can also comment on this, but I'd ideally like to see us move to a place where we use this simple structure for all resources, regardless of type. If we do that, then there isn't necessarily any reason to have a separate GenericXdsConfigDump
message for each resource type; we could instead just send all resources in a single GenericXdsConfigDump
message.
Note that once we move to new-style resource names, there's no wire-size savings to be had here by putting each resource type into its own message, because the resource type will be part of the individual resource names anyway.
aee3fb1
to
46c2b3d
Compare
Described in #15622 . Some use cases
|
f13559d
to
8f4eeab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markdroth any further comment or does this look good to you? I need a non-tetrands review.
…t docs yet) Signed-off-by: su225 <[email protected]>
Signed-off-by: su225 <[email protected]>
453e846
to
7097451
Compare
I like this direction, but I'd like to get input from folks like @htuch, @mattklein123, @fuqianggao, and @lidizheng to make sure that we're all bought-in on the idea of using a single representation for all resource types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this change. This makes both assembling and parsing the CSDS response much simpler.
One question I have is for static resources. Admin config dump differentiate static resources given by yaml file and dynamic resources updated by control plane. Should we send static resources as GenericXdsConfig
as well?
Also, for ECDS, are we going to expose them via the normal HTTP config dump page?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
High level idea LGTM
string type_url = 1; | ||
|
||
// name of the xDS resource | ||
string name = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean that this represent a single resource? I am a bit concerned that the resources are not grouped by resource type, might have worse UX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it represents a single resource.
In practice, I suspect that most implementations will send all resources of the same type next to each other anyway, simply because that's the obvious way to implement CSDS. But you're right that there is no requirement to do that here.
Keep in mind, though, that even if the server doesn't group those resources together, the client can always group them that way for display purposes. I think the API and the UX can be handled independently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SG.
+1 I like this direction. Can we just deprecate the old way and use the new way as the only supported way? |
Oops nevermind I see you did deprecate it. +1 |
Good question. Do we care about the distinction between static and dynamic resources from the perspective of CSDS? The Envoy folks will need to weigh in on this. gRPC doesn't support static resources, so we don't need this. If this distinction is important, we could add a bool to the message indicating that the resource is static. Would that be sufficient? |
I think it makes sense to include static, since this is the experience that folks working with the admin interface are used to. I agree with adding a bool (or enum?) to distinguish. |
Signed-off-by: su225 <[email protected]>
/lgtm api |
Signed-off-by: su225 <[email protected]>
Signed-off-by: su225 <[email protected]>
Signed-off-by: su225 <[email protected]>
@htuch - Added the flag. |
Thanks. @fuqianggao can you take another pass? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
please specify a single label can be specified |
Signed-off-by: su225 <[email protected]>
Signed-off-by: su225 <[email protected]>
Signed-off-by: su225 <[email protected]>
TODO
Commit Message: Enhanced CSDS API to support reporting status for generic xDS resource types
Additional Description:
Risk Level: Low
Docs Changes: Inline protobuf docs (not done yet)
Release Notes: Enhanced CSDS API to support reporting status for generic xDS resource types
[Optional Fixes #15622]