envoyproxy / envoyproxy/envoy

config: partial rejections in incremental xDS

Open
#5,739 24 comments 1 reaction 0 assignees View on GitHub
design proposal help wanted
Dominant language
C++
Stars
28.9k
Forks
5.6k
Avg merge
1d 20h
Merged PRs (30d)
437

Description

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.