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
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 53 additions & 1 deletion api/envoy/service/status/v3/csds.proto
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,8 @@ import "envoy/config/core/v3/base.proto";
import "envoy/type/matcher/v3/node.proto";

import "google/api/annotations.proto";
import "google/protobuf/any.proto";
import "google/protobuf/timestamp.proto";

import "envoy/annotations/deprecation.proto";
import "udpa/annotations/status.proto";
Expand Down Expand Up @@ -124,10 +126,60 @@ message ClientConfig {
option (udpa.annotations.versioning).previous_message_type =
"envoy.service.status.v2.ClientConfig";

// GenericXdsConfig is used to specify the config status and the dump
// of any xDS resource identified by their type URL. It is the generalized
// version of the now deprecated ListenersConfigDump, ClustersConfigDump etc
// [#next-free-field: 10]
message GenericXdsConfig {
// Type_url represents the fully qualified name of xDS resource type
// like envoy.v3.Cluster, envoy.v3.ClusterLoadAssignment etc.
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.


// This is the :ref:`version_info <envoy_v3_api_field_service.discovery.v3.DiscoveryResponse.version_info>`
// in the last processed xDS discovery response. If there are only
// static bootstrap listeners, this field will be ""
string version_info = 3;

// The xDS resource config. Actual content depends on the type
google.protobuf.Any xds_config = 4;

// Timestamp when the xDS resource was last updated
google.protobuf.Timestamp last_updated = 5;

// Per xDS resource config status. It is generated by management servers.
// It will not be present if the CSDS server is an xDS client.
ConfigStatus config_status = 6;

// Per xDS resource status from the view of a xDS client
admin.v3.ClientResourceStatus client_status = 7;

// Set if the last update failed, cleared after the next successful
// update. The *error_state* field contains the rejected version of
// this particular resource along with the reason and timestamp. For
// successfully updated or acknowledged resource, this field should
// be empty.
// [#not-implemented-hide:]
admin.v3.UpdateFailureState error_state = 8;

// Is static resource is true if it is specified in the config supplied
// through the file at the startup.
bool is_static_resource = 9;
}

// Node for a particular client.
config.core.v3.Node node = 1;

repeated PerXdsConfig xds_config = 2;
// This field is deprecated in favor of generic_xds_configs which is
// much simpler and uniform in structure.
repeated PerXdsConfig xds_config = 2
[deprecated = true, (envoy.annotations.deprecated_at_minor_version) = "3.0"];

// Represents generic xDS config and the exact config structure depends on
// the type URL (like Cluster if it is CDS)
repeated GenericXdsConfig generic_xds_configs = 3;
su225 marked this conversation as resolved.
Show resolved Hide resolved
}

message ClientStatusResponse {
Expand Down
56 changes: 55 additions & 1 deletion api/envoy/service/status/v4alpha/csds.proto

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

54 changes: 53 additions & 1 deletion generated_api_shadow/envoy/service/status/v3/csds.proto

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

57 changes: 56 additions & 1 deletion generated_api_shadow/envoy/service/status/v4alpha/csds.proto

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.