-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Add independent lock #3247
Comments
What is the purpose of this class? We have several implementations of Lock already: |
Actions which require a distributed lock. How can lock/unlock usage be achieved with existing lock ?
|
Is it that you want to be able to There's not much difference between locking and leader election (except perhaps the unlock part) so I'd prefer to extend the existing implementations. |
Existing LeaseLock implements io.kubernetes.client.extended.leaderelection.Lock, which is "strictly for use by the leaderelection code". Adding to it can feel like abuse.
|
I think it's definitely fine to implement That code is tricky to get right and we're better off focusing on a single implementation. |
Is this interface/implementation the most suitable for the job of a "distributed lock"? As far as I understand, the leader election feature is aimed to "determine the current leader and keep the other replicas as followers", in the sense that the leader will continue to be a leader except when it stops sending updates. For distributed locks maybe one can use Redisson RLocks for example, or any other distributed lock implementation. We've been using RLocks for a while and it works pretty well. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
Description
Add a lock class, not depends on leader election.
Usage high level guideline:
Use cases
Actions which require distributed lock.
Solution suggestion
implementation details - high level
Note that I have this implementation ready, so if confirmed, I can try opening a PR for it at extended module.
Would appreciate feedback on proceeding with it.
The text was updated successfully, but these errors were encountered: