Skip to content

cds: fix blocking a revert of a warming cluster#15269

Merged
mattklein123 merged 2 commits intoenvoyproxy:mainfrom
tbarrella:revert-warming
Mar 5, 2021
Merged

cds: fix blocking a revert of a warming cluster#15269
mattklein123 merged 2 commits intoenvoyproxy:mainfrom
tbarrella:revert-warming

Conversation

@tbarrella
Copy link
Copy Markdown
Contributor

Commit Message:
cds: fix blocking a revert of a warming cluster

Signed-off-by: Taylor Barrella tabarr@google.com

Additional Description:
Risk Level: Low
Testing: Unit test
Docs Changes: N/A
Release Notes: Noted bug fix
Fixes #14598

Signed-off-by: Taylor Barrella <tabarr@google.com>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing. Just a request for more comments please.

/wait

Signed-off-by: Taylor Barrella <tabarr@google.com>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

existing_active_cluster->second->blockUpdate(new_hash)) ||
(existing_warming_cluster != warming_clusters_.end() &&
existing_warming_cluster->second->blockUpdate(new_hash))) {
if (existing_warming_cluster != warming_clusters_.end()) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattklein123 @tbarrella do you think the same issue may exist in LDS in

// The listener should be updated back to its original state and the warming listener should be
?

It's hard for me to tell, since the logic here is subtle and orders are different.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's from #12645 which looks like it was meant to fix the same issue with LDS. I guess the approach is different; I didn't do it that way because it seemed simpler to take the newest config as a typical update rather than introduce cancellation

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to factor out this pattern? Divergence seems scary :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hear what you mean in terms of divergence. For this do you mean actual code refactoring (I'm not sure about the ROI here) or just making sure the logic is the same? What are your thoughts on the LDS (cancel the warming listener and block the current update) vs. CDS approach (accept the current update)?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel strongly on how we do it as long as we make them consistent and keep them that way (code comments explaining when to update what? Structural is always nicer if it's not too much complexity).

I think whatever is simplest here makes sense, but CC @adisuissa @dmitri-d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Envoy drops CDS update at high churn rate

3 participants