Skip to content

api: LEDS api introduction #17419

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

Merged
mattklein123 merged 7 commits into from
Aug 4, 2021
Merged

api: LEDS api introduction #17419

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
174ad80
api: LEDS api introduction
adisuissa Jul 20, 2021
56f44b0
Adding missing proto files
adisuissa Jul 20, 2021
96a4ed8
Removing oneof
adisuissa Jul 21, 2021
9d31e22
Using oneof with a list
adisuissa Jul 27, 2021
5d49958
Merge remote-tracking branch 'upstream/main' into leds_api
adisuissa Jul 27, 2021
da0db40
Removing unused import
adisuissa Jul 27, 2021
9e5bb43
Merge remote-tracking branch 'upstream/main' into leds_api
adisuissa Jul 27, 2021
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
2 changes: 1 addition & 1 deletion api/envoy/config/cluster/v4alpha/BUILD
View file
Open in desktop

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

4 changes: 2 additions & 2 deletions api/envoy/config/cluster/v4alpha/cluster.proto
View file
Open in desktop

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

24 changes: 22 additions & 2 deletions api/envoy/config/endpoint/v3/endpoint_components.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,12 @@ package envoy.config.endpoint.v3;

import "envoy/config/core/v3/address.proto";
import "envoy/config/core/v3/base.proto";
import "envoy/config/core/v3/config_source.proto";
import "envoy/config/core/v3/health_check.proto";

import "google/protobuf/wrappers.proto";

import "udpa/annotations/migrate.proto";
import "udpa/annotations/status.proto";
import "udpa/annotations/versioning.proto";
import "validate/validate.proto";
Expand Down Expand Up @@ -108,11 +110,22 @@ message LbEndpoint {
google.protobuf.UInt32Value load_balancing_weight = 4 [(validate.rules).uint32 = {gte: 1}];
}

// [#not-implemented-hide:]
// A configuration for a LEDS collection.
message LedsClusterLocalityConfig {
// Configuration for the source of LEDS updates for a Locality.
core.v3.ConfigSource leds_config = 1;

// The xDS transport protocol glob collection resource name.
// The service is only supported in delta xDS (incremental) mode.
string leds_collection_name = 2;
}

// A group of endpoints belonging to a Locality.
// One can have multiple LocalityLbEndpoints for a locality, but this is
// generally only done if the different groups need to have different load
// balancing weights or different priorities.
// [#next-free-field: 7]
// [#next-free-field: 8]
message LocalityLbEndpoints {
option (udpa.annotations.versioning).previous_message_type =
"envoy.api.v2.endpoint.LocalityLbEndpoints";
Expand All @@ -121,7 +134,14 @@ message LocalityLbEndpoints {
core.v3.Locality locality = 1;

// The group of endpoints belonging to the locality specified.
repeated LbEndpoint lb_endpoints = 2;
repeated LbEndpoint lb_endpoints = 2
[(udpa.annotations.field_migrate).oneof_promotion = "lb_config"];

@markdroth markdroth Jul 21, 2021

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think it's legal to have a repeated field in a oneof, so this oneof_promotion won't actually work. :(

@adisuissa adisuissa Jul 21, 2021

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes you are correct, thanks!
I think the right way would be to support both lb_endpoints and the leds_cluster_locality_config (similar to what's being done for VHDS). I've looked at my implementation and it won't require much change.

@markdroth markdroth Jul 21, 2021

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Alternatively, consider deprecating the existing lb_endpoints field and replacing it with a message that contains the repeated field, and then putting that message in the oneof. In other words, add this message:

message LbEndpoints {
  repeated LbEndpoint lb_endpoints = 1;
}

And then change the fields here to:

// Deprecated -- use inline_endpoints instead.
repeated LbEndpoint lb_endpoints = 2 [deprecated = true];

oneof endpoints {
  LbEndpoints inline_endpoints = 7;
  LedsClusterLocalityConfig leds_cluster_locality_config = 8;
}


oneof lb_config {
// [#not-implemented-hide:]
// LEDS Configuration for the current locality.
LedsClusterLocalityConfig leds_cluster_locality_config = 7;
}

// Optional: Per priority/region/zone/sub_zone weight; at least 1. The load
// balancing weight for a locality is divided by the sum of the weights of all
Expand Down
14 changes: 14 additions & 0 deletions api/envoy/config/endpoint/v4alpha/BUILD
View file
Open in desktop

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

119 changes: 119 additions & 0 deletions api/envoy/config/endpoint/v4alpha/endpoint.proto
View file
Open in desktop

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

179 changes: 179 additions & 0 deletions api/envoy/config/endpoint/v4alpha/endpoint_components.proto
View file
Open in desktop

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

Loading