search

sorintlab / stolon

PostgreSQL cloud native High Availability and more.
https://talk.stolon.io
Apache License 2.0
4.66k stars 447 forks source link

Support additional stores #100

Closed sgotti closed 6 years ago

sgotti commented 8 years ago

It'll be good to support additional stores like consul and zookeper.

sgotti commented 8 years ago

Done in #102. Now https://github.com/hashicorp/consul can be used since we are using https://github.com/docker/libkv. Zookeeper is not currently enabled since it needs integration tests.

sergik commented 7 years ago

As far as I understnd only etcd 2 is supported. Could etcd 3 also be supported? Also using of kubernetes Thirdparty resources as store will be also very useful for hosting in kubernetes. This will allow use of solon without any additional tools in kubernetes.

sgotti commented 7 years ago

@sergik stolon works also with etcd3 (our integration tests are currently run with etcd v3.1.8). It just uses the v2 api since we are using libkv that unfortunately doesn't support etcdv3.

The downside is that the v2 api uses a different store that the v3 api and if you want to read the stolon data from an external application (discouraged) you have to use the v2 api.

Looks like libkv is not very maintaned so a solution will be to keep it for consul and etcdv2 and implement a new etcdv3 store.

Also using of kubernetes Thirdparty resources as store will be also very useful for hosting in kubernetes. This will allow use of solon without any additional tools in kubernetes.

I haven't investigated if thirdparty resources cover all the use cases we need.

I just saw that flannel can use k8s as a subnetmanager in alternative to etcd (https://github.com/coreos/flannel/blob/master/subnet/kube/kube.go) and there're some leader election examples (https://github.com/kubernetes/contrib/tree/master/election).

Also in this case a new stolon store implementation could be added.

Are you willing to investigate more on this and perhaps open a PR?

sergik commented 7 years ago

I haven't investigated if thirdparty resources cover all the use cases we need.

To my mind a good example of using TPR as config store is etcd-opeartor etcd

Also in this case a new stolon store implementation could be added.

I looked into current implementation. Looks like it is hardly depends on libkv. Does not looks very easy to add new store which not depends on libkv. But I found libkv fork which adds a etcdv3 implementation which implements required for stolon interface. here Could we start from adding this? Or mb we can discuss your vision of storage abstraction refactor to support different providers.

sgotti commented 7 years ago

I looked into current implementation. Looks like it is hardly depends on libkv. Does not looks very easy to add new store which not depends on libkv. But I found libkv fork which adds a etcdv3 implementation which implements required for stolon interface. here Could we start from adding this? Or mb we can discuss your vision of storage abstraction refactor to support different providers.

I'm inclined to just remove libkv support and create our own minimal store interface. The reasons are different, for example we really need to implement golang context pkg so we can timeout and not block calls to an external store (and I'd like to avoid depending on an unmaintained project or one of its forks)

In this way we can also implement a k8s store.

sgotti commented 6 years ago

PR for etcd v3 api: #393

sgotti commented 6 years ago

etcv3 support has been implemented in #393. Let's close this issue and open new ones when new stores backend should be added.