-
Notifications
You must be signed in to change notification settings - Fork 273
Update xDS docs to clarify ordering #206
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
Changes from all commits
566e122
6aed0e5
ff6eeea
523a11a
a00975f
867aac0
a729bc1
9456f27
6b7220f
5e0d5c2
3819e57
1c0144a
e0dd931
b867cc5
e6f8369
f331fa8
889628a
8638cbb
8cb7a69
7502b0c
81186d7
95286bb
7ba311c
3412880
3d0bfda
f01ef4f
24da3eb
3abb345
c7784fb
77ce4e8
c3665d4
74d96b6
c50c5e9
69c9237
e86b9e5
b5e4eea
1f13aeb
91bc65f
c22f482
1a391c4
bc04f80
5710cec
6f44ef7
2c138d9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -191,11 +191,23 @@ drop can't be tolerated, traffic drop could have been avoided by providing a | |
| CDS/EDS update with both __X__ and __Y__, then the RDS update repointing from | ||
| __X__ to __Y__ and then a CDS/EDS update dropping __X__. | ||
|
|
||
| In general, to avoid traffic drop: | ||
| * Sequencing should be make before break. | ||
| * LDS and CDS updates should arrive before the respective RDS and EDS updates. | ||
| * 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 | ||
| * 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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). |
||
| * 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 | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
| are added or if it's acceptable to temporarily drop traffic during | ||
| updates. Note that in case of LDS updates, the listeners will be warmed | ||
| before they receive traffic, i.e. the dependent routes are fetched through | ||
| RDS if configured. On the other hand, clusters are not warmed when | ||
| adding/removing/updating clusters. Similarly, routes are not warmed -- | ||
| i.e., the management plane must ensure that clusters referenced by a route | ||
| are in place, before pushing the updates for a rotue. | ||
|
|
||
| ### Aggregated Discovery Services (ADS) | ||
|
|
||
|
|
||
This file was deleted.
This file was deleted.
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 quoteshere, but instead MD emphasis. Not worth changing unless you need another revision though.