Given Consul's popularity, seems like someone could make an argument that we should be shipping a consul-aware seed provider.
On Tue, Jan 8, 2019 at 7:39 AM Jonathan Ballet <jbal...@edgelab.ch> wrote: > On Mon, 7 Jan 2019 at 16:51, Oleksandr Shulgin < > oleksandr.shul...@zalando.de> wrote: > >> On Mon, Jan 7, 2019 at 3:37 PM Jonathan Ballet <jbal...@edgelab.ch> >> wrote: >> >>> >>> I'm working on how we could improve the upgrades of our servers and how >>> to replace them completely (new instance with a new IP address). >>> What I would like to do is to replace the machines holding our current >>> seeds (#1 and #2 at the moment) in a rolling upgrade fashion, on a regular >>> basis: >>> >>> * Is it possible to "promote" any non-seed node as a seed node? >>> >>> * Is it possible to "promote" a new seed node without having to restart >>> all the nodes? >>> In essence, in my example that would be: >>> >>> - decide that #2 and #3 will be the new seed nodes >>> - update all the configuration files of all the nodes to write the IP >>> addresses of #2 and #3 >>> - DON'T restart any node - the new seed configuration will be picked >>> up only if the Cassandra process restarts >>> >> >> You can provide a custom implementation of the seed provider protocol: >> org.apache.cassandra.locator.SeedProvider >> >> We were exploring that approach few years ago with etcd, which I think >> provides capabilities similar to that of Consul: >> https://github.com/a1exsh/cassandra-etcd-seed-provider/blob/master/src/main/java/org/zalando/cassandra/locator/EtcdSeedProvider.java >> > > Hi Alex, > > we were using also a dedicated Consul seed provider but we weren't > confident enough about maintaining our version so we removed it in favor of > something simpler. > Ultimately, we hope(d) that delegating the maintenance of that list to an > external process (like Consul Template), directly updating the > configuration file, is (should be?) mostly similar without having to > maintain our own copy, built with the right version of Cassandra, etc. > > Thanks for the info though! > > Jonathan > >
