Skip to content
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

fix: Correct operator leader election ConfigMap lock name #1765

Merged
merged 1 commit into from
Oct 15, 2020
Merged

fix: Correct operator leader election ConfigMap lock name #1765

merged 1 commit into from
Oct 15, 2020

Conversation

astefanutti
Copy link
Member

Fixes the discrepancy introduced with #1741.

Release Note

NONE

@heiko-braun
Copy link

Out of curiosity, what do we need lesder election for? What leader election protocol does it use?

@astefanutti
Copy link
Member Author

Out of curiosity, what do we need leader election for? What leader election protocol does it use?

It is to make sure only one operator instance operates on the controlled custom resources. Technically, it is just a ConfigMap that materialises a lock.

@astefanutti astefanutti merged commit 176ae05 into apache:master Oct 15, 2020
@astefanutti astefanutti deleted the pr-142 branch October 15, 2020 12:08
@astefanutti
Copy link
Member Author

Adding that, on a typical production environment, an operator deployment is likely to be scaled up to achieve high availability, leading to multiple instances, among which only one can actually operates on the custom resources.

@nicolaferraro nicolaferraro mentioned this pull request Dec 22, 2020
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.

3 participants