On Nov 4, 2015, at 4:41 PM, Gregory Haynes <g...@greghaynes.net> 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<dava...@gmail.com> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
