Cache ADS Mode Snapshot Consistency Question about go-control-plane HOT 4 CLOSED

The reasoning for holding the request was that we would need to generate multiple intermediate versions for EDS responses. A simple example is that let's say we have two clusters C1 and C2, and envoy requests:

1. EDS for {C1}
2. EDS for {C1, C2}

If we respond to request 1 with version X, then we need a new version Y for request 2. Generating this intermediate versions is certainly possible, but what we have now would simply not respond to request 1, and instead respond to request 2 with version X. This allows a simpler versioning scheme for snapshots (e.g. just set the whole config snapshot to version X, and converge on all proxies being at version X).

from go-control-plane.

Thanks for the reply, @kyessenov.

The sequence you outlined makes sense to me. I'm wondering if you have any suggestions for how to avoid the deadlock issue I described above? IMO it seems a bit too coupled that our control plane and each Envoy instance have to be on the same page about what clusters are declared statically in the Envoy's config and which should be sent through CDS. As it stands right now, it feels a bit fragile.

from go-control-plane.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

from go-control-plane.

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

from go-control-plane.