-
Notifications
You must be signed in to change notification settings - Fork 270
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
Update xDS docs to clarify ordering #206
Conversation
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
* CDS updates (if any) must always be pushed first. | ||
* EDS updates (if any) must arrive after CDS updates for the respective clusters. | ||
* LDS updates must arrive after corresponding CDS/EDS updates. | ||
* RDS updates related to the newly added listeners must arrive in the end. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should explain the "break" bit afterwards, where you clean up the old clusters (for example).
XDS_PROTOCOL.md
Outdated
* RDS updates related to the newly added listeners must arrive in the end. | ||
|
||
xDS updates can be pushed independently if no new clusters/routes/listeners | ||
are added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or if it's acceptable to temporarily drop traffic during updates (this is after all the whole point of the eventual consistency model, some folks don't mind dropping traffic or inconsistent routing across nodes if it makes management simpler).
XDS_PROTOCOL.md
Outdated
* LDS updates must arrive after corresponding CDS/EDS updates. | ||
* RDS updates related to the newly added listeners must arrive in the end. | ||
|
||
xDS updates can be pushed independently if no new clusters/routes/listeners |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is too strong and not accurate I think. You can add a route that refers to existing clusters, for example, with a completely independent RDS update. Also, if you modify a cluster, it will need to go out and fetch its corresponding EDS update, see https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/envoy-users/jn3VJJBGoPo/Z_EpNSk2BgAJ. We probably need CDS/EDS warming to be implemented to make updates safe from dropping traffic (otherwise, you probably need to do a full RDS/CDS/EDS update sequence with new cluster name to avoid drops).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should i remove it altogether?
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
Signed-off-by: Shriram Rajagopalan <[email protected]>
ci/build_setup.sh
Outdated
exit 1 | ||
fi | ||
mkdir -p ${BUILD_DIR} | ||
# if [[ ! -d "${BUILD_DIR}" ]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please just delete this vs. comment.
XDS_PROTOCOL.md
Outdated
* EDS updates (if any) must arrive after CDS updates for the respective clusters. | ||
* LDS updates must arrive after corresponding CDS/EDS updates. | ||
* RDS updates related to the newly added listeners must arrive in the end. | ||
* Stale CDS clusters (ones no longer being referenced) can then be removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.. and also related EDS.
Signed-off-by: Shriram Rajagopalan <[email protected]>
XDS_PROTOCOL.md
Outdated
referenced) can then be removed. | ||
|
||
xDS updates can be pushed independently if no new clusters/routes/listeners | ||
are added or or if it's acceptable to temporarily drop traffic during updates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo "or or"
Signed-off-by: Shriram Rajagopalan <[email protected]>
* CDS/EDS resources corresponding to routes in LDS/RDS should be available at | ||
update. | ||
In general, to avoid traffic drop, sequencing of updates should follow a | ||
`make before break` model, wherein |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't use verbatim quotes
here, but instead MD emphasis. Not worth changing unless you need another revision though.
* Stale CDS clusters and related EDS endpoints (ones no longer being | ||
referenced) can then be removed. | ||
|
||
xDS updates can be pushed independently if no new clusters/routes/listeners |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My previous comment on this wasn't reflected in the text here; there are some nuances that should be communicated that were there, in particular around the lack of CDS/EDS warming and the safety of independent updates for new clusters/routes that have no relationship with existing ones.
Is there a rough text that I can use as base? |
@rshriram I think @htuch is looking for a short description around the fact that a) we do warm listeners (https://www.envoyproxy.io/envoy/configuration/listeners/lds), but we don't currently warm clusters (envoyproxy/envoy#1930). You should be able to craft a short statement from both of those and/or link. It's unclear to me how high priority warming CDS actually is. I think it's actually pretty uncommon use case that people update clusters. Add/remove is much more common. |
Signed-off-by: Shriram Rajagopalan <[email protected]>
I added some text. PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks.
No description provided.