I will be working on adding the Consul driver to Tooz [1]. -Vilobh [1] https://blueprints.launchpad.net/python-tooz/+spec/add-consul-driver
On Wed, Nov 4, 2015 at 2:05 PM, Mark Voelker <[email protected]> wrote: > On Nov 4, 2015, at 4:41 PM, Gregory Haynes <[email protected]> wrote: > > > > Excerpts from Clint Byrum's message of 2015-11-04 21:17:15 +0000: > >> Excerpts from Joshua Harlow's message of 2015-11-04 12:57:53 -0800: > >>> Ed Leafe wrote: > >>>> On Nov 3, 2015, at 6:45 AM, Davanum Srinivas<[email protected]> > wrote: > >>>>> Here's a Devstack review for zookeeper in support of this initiative: > >>>>> > >>>>> https://review.openstack.org/241040 > >>>>> > >>>>> Thanks, > >>>>> Dims > >>>> > >>>> I thought that the operators at that session made it very clear that > they would *not* run any Java applications, and that if OpenStack required > a Java app to run, they would no longer use it. > >>>> > >>>> I like the idea of using Zookeeper as the DLM, but I don't think it > should be set up as a default, even for devstack, given the vehement > opposition expressed. > >>>> > >>> > >>> What should be the default then? > >>> > >>> As for 'vehement opposition' I didn't see that as being there, I saw a > >>> small set of people say 'I don't want to run java or I can't run java', > >>> some comments about requiring using oracles JVM (which isn't correct, > >>> OpenJDK works for folks that I have asked in the zookeeper community > and > >>> else where) and the rest of the folks were ok with it... > >>> > >>> If people want a alternate driver, propose it IMHO... > >>> > >> > >> The few operators who stated this position are very much appreciated > >> for standing up and making it clear. It has helped us not step into a > >> minefield with a native ZK driver! > >> > >> Consul is the most popular second choice, and should work fine for the > >> use cases we identified. It will not be sufficient if we ever have > >> a use case where many agents must lock many resources, since Consul > >> does not offer a way to grant lock access in a fair manner (ZK does, > >> and we're not aware of any others that do actually). Using Consul or > >> etcd for this case would result in situations where lock waiters may > >> wait _forever_, and will likely wait longer than they should at times. > >> Hopefully we can simply avoid the need for this in OpenStack all > together. > >> > >> I do _not_ think we should wait for constrained operators to scream > >> at us about ZK to write a Consul driver. It's important enough that we > >> should start documenting all of the issues we expect to see with Consul > >> (it's not widely packaged, for instance) and writing a driver with its > >> own devstack plugin. > >> > >> If there are Consul experts who did not make it to those sessions, > >> it would be greatly appreciated if you can spend some time on this. > >> > >> What I don't want to see happen is we get into a deadlock where there's > >> a large portion of users who can't upgrade and no driver to support > them. > >> So lets stay ahead of the problem, and get a set of drivers that works > >> for everybody! > >> > > > > One additional note - out of the three possible options I see for tooz > > drivers in production (zk, consul, etcd) we currently only have drivers > > for ZK. This means that unless new drivers are created, when we depend > > on tooz we will be requiring folks deploy zk. > > > > It would be *awesome* if some folks stepped up to create and support at > > least one of the aternate backends. > > > > Although I am a fan of the ZK solution, I have an old WIP patch for > > creating an etcd driver. I would like to revive and maintain it, but I > > would also need one more maintainer per the new rules for in tree > > drivers… > > For those following along at home, said WIP etcd driver patch is here: > > https://review.openstack.org/#/c/151463/ > > And said rules are at: > > https://review.openstack.org/#/c/240645/ > > And FWIW, I too am personally fine with ZK as a default for devstack. > > At Your Service, > > Mark T. Voelker > > > > > Cheers, > > Greg > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
