envoyproxy / envoyproxy/envoy

config: partial rejections in incremental xDS

Offen
#5,739 24 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen
design proposal help wanted
Vorherrschende Sprache
C++
Sterne
28.9k
Forks
5.6k
Ø Merge
1 T. 22 Std.
Gemergte PRs (30 T.)
430

Beschreibung

In the review of #5466, the issue of partial rejections (when some resources have errors, but you still want to apply the rest and tell the xDS server you did so) came up. It was previously requested/discussed in #3079, but the current thinking is that *only* incremental xDS will have this feature, so I figured it deserved a new issue.

The incremental xDS gRPC protocol, as defined by [IncrementalDiscoveryRequest](https://github.com/envoyproxy/envoy/blob/master/api/envoy/api/v2/discovery.proto#L124), does not currently support partial rejections; there is just a single "here is why everything failed" grpc::Status field, just as in standard xDS. How should this proto support the partial rejection feature?

@htuch and I briefly discussed how this might be done, and saw two options so far:

- Replace the grpc::Status error_detail field with a repeated grpc::Status field, expected to be as long as the number of resources in the previous IncrementalDiscoveryResponse. Entries correspond by index to the resources in that previous message.
- Have a map from resource names to errors. ~~This approach would be complicated by the fact that resource name lives inside an opaque Any.~~

There is also the question of whether we want to be able to distinguish between "each and every resource individually had errors" and "your whole update attempt had an error", i.e. whether the existing error_detail field should remain alongside the new partial rejection mechanism.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.