question about libkv HOT 5 CLOSED

Hi @prateekgogia,

Yes, if a store backend supports most of the calls specified in the Store interface, it can be leveraged through libkv. For example we can think about adding a redis driver. I'm currently working on implementing an additional driver for irmin a git-like storage that implements most of this Store interface.

Any store that has Put/Get/List/Watch and CAS can be used with docker by specifying --cluster-store. A driver can still be implemented without full support for the Store interface but that does brake the abstraction and this means that you will not be able to use it seamlessly alongside consul, etcd or zookeeper (you'll have to handle special cases, etc.).

We cannot point to any store though. Each store backend is supported through its own driver here in libkv (by calling their respective client library to communicate with the remote store).

from libkv.

@abronan Thanks for your reply.
What if I write a Http based store backend, and write a driver for it to be included in libkv. Now we could specify
DOCKER_OPTS="--cluster-store=httpstore://1.2.3.4:5000/...
and this backend store at 1.2.3.4 can be like a generic REST server running, which implements all the Store interface mentioned above.
Now, for each docker daemon I can specify this store and it accepts KV data over http through driver/client in libkv.
Do you think something of this sort will be accepted ?

from libkv.

Hi @abronan any comments on the request above ?

from libkv.

@prateekgogia Sorry for the long delay in the reply. The problem in using a generic approach is that we end with no consistency guarantees (whether weak or strong). Which makes the code way more complex on the application side, now I need to take care of all the edge cases where the data could be stale because I have no idea what's behind.

Of course this can be done but the goal of the abstraction is to make sure we register only the kind of store that make sense at the application level. So if we require strong consistency guarantees, we are going to register consul, etcd and zookeeper together. If I don't need this guarantee I can hypothetically register a redis or a simpleDB driver (if those were implemented), etc.

Writing such a driver is definitely possible, but the problem lies in what's behind the REST API? What are the guarantees provided with the store, the calls supported? etc.

from libkv.

Closing this one, but feel free to jump in or open a new issue if you have any more questions or issues to report. Thanks!

from libkv.