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

[envoy-15622] add generic XDS protobuf definitions #15760

Merged
merged 8 commits into from
Jun 2, 2021

Conversation

su225
Copy link
Contributor

@su225 su225 commented Mar 30, 2021

TODO

  • Refine protobuf messages and add it to different versions of the API
  • Add and refine inline documentation

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]

@repokitteh-read-only
Copy link

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.

🐱

Caused by: #15760 was opened by su225.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
API shepherd assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #15760 was opened by su225.

see: more, trace.

@mattklein123
Copy link
Member

Can you provide some background context on this PR? Thank you.

/wait

api/envoy/admin/v3/config_dump.proto Outdated Show resolved Hide resolved
api/envoy/service/status/v3/csds.proto Outdated Show resolved Hide resolved
UpdateFailureState error_state = 6;
}

string type_url = 1;
Copy link
Contributor

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.

api/envoy/admin/v3/config_dump.proto Outdated Show resolved Hide resolved
api/envoy/service/status/v3/csds.proto Outdated Show resolved Hide resolved
api/envoy/admin/v3/config_dump.proto Outdated Show resolved Hide resolved
api/envoy/admin/v3/config_dump.proto Outdated Show resolved Hide resolved
api/envoy/service/status/v3/csds.proto Outdated Show resolved Hide resolved
@su225 su225 force-pushed the 15622-generic-csds-api branch from aee3fb1 to 46c2b3d Compare April 8, 2021 17:45
@su225
Copy link
Contributor Author

su225 commented Apr 8, 2021

Can you provide some background context on this PR? Thank you.

Described in #15622 . Some use cases

  • As Envoy adds more xDS config types, the API would get more complex to support new types. Some like ECDS don't have support at the moment.
  • There are some projects like Istio which also have additional xDS types like NDS (Name Discovery Service), PCDS (Proxy Config Discovery Service). Technically "istio-agent+envoy" forms the dataplane in Istio. From the point of view of other UDPA implementations, it makes sense to define their own xDS types for their specific usecase without having to upstream to Envoy, but still use the same kind of API. This is helpful to use it with generic UDPA related tooling.

@su225 su225 requested a review from lizan April 8, 2021 18:14
@su225 su225 force-pushed the 15622-generic-csds-api branch from f13559d to 8f4eeab Compare May 2, 2021 12:28
@su225 su225 changed the title [envoy-15622][WIP] add generic XDS protobuf definitions [envoy-15622] add generic XDS protobuf definitions May 2, 2021
@su225 su225 requested a review from markdroth May 13, 2021 13:59
Copy link
Member

@lizan lizan left a 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.

api/envoy/service/status/v3/csds.proto Show resolved Hide resolved
@su225 su225 requested a review from lizan May 19, 2021 08:40
@su225 su225 force-pushed the 15622-generic-csds-api branch from 453e846 to 7097451 Compare May 19, 2021 18:14
@markdroth
Copy link
Contributor

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.

Copy link
Contributor

@lidizheng lidizheng left a 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?

api/envoy/service/status/v3/csds.proto Outdated Show resolved Hide resolved
Copy link
Contributor

@fuqianggao fuqianggao left a 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;
Copy link
Contributor

@fuqianggao fuqianggao May 20, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SG.

@mattklein123
Copy link
Member

+1 I like this direction. Can we just deprecate the old way and use the new way as the only supported way?

@mattklein123
Copy link
Member

Oops nevermind I see you did deprecate it. +1

@markdroth
Copy link
Contributor

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?

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?

@htuch
Copy link
Member

htuch commented May 23, 2021

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.

@markdroth
Copy link
Contributor

/lgtm api

@su225
Copy link
Contributor Author

su225 commented May 26, 2021

@htuch - Added the flag.

@htuch
Copy link
Member

htuch commented May 28, 2021

Thanks. @fuqianggao can you take another pass?

Copy link
Contributor

@fuqianggao fuqianggao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

api/envoy/service/status/v3/csds.proto Outdated Show resolved Hide resolved
@repokitteh-read-only
Copy link

please specify a single label can be specified

🐱

Caused by: a #15760 (review) was submitted by @fuqianggao.

see: more, trace.

@su225 su225 requested a review from htuch May 30, 2021 14:48
@repokitteh-read-only repokitteh-read-only bot removed the api label Jun 2, 2021
@mattklein123 mattklein123 merged commit 53d8c9d into envoyproxy:main Jun 2, 2021
leyao-daily pushed a commit to leyao-daily/envoy that referenced this pull request Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support generic CSDS types
7 participants