libkv
libkv copied to clipboard
Fix Lock abstraction across distributed store backends
The Lock abstraction is inconsistent across distributed backends mostly because etcd expects the key not to exist for the mechanism to work.
This is due to the custom Lock implementation using atomic key creation as a fence for lock seekers. etcd api v3 will have it's own Lock implementation so the behavior should be fixed when migrating to the new API.
Related to #103
Would also be good to implement a distinction between a read and write lock
+1 on this, the resulting traefik bug is very anoying...