On 10/31/2013 01:32 PM, Joshua Harlow wrote: > In the spirt of openness, yes I do think they are all needed. > > If they are not supported, then openstack is not open, it is a closed > system. > > We should strive to innovate, not strive to be stuck with the status quo. > > To me it is a developers decision to pick the right solution, if that > solution involves some complexity then u make it a pluggable solution. > Your view of the right solution will likely not be the view of someone > elses right solution in the end anyway (and u likely can't predict future > solutions that will be applicable anyway). If u just say no to that plugin > then u are just excluding people from participating in your project and > this is imho against the spirt of openness in general. And those people > who would have contributed will just start looking elsewhere for a > solution which does work. This kills the openstack...
Hrm. I certainly don't want to kill openstack, and I _certainly_ don't want to disallow a plugin. I apologize if it came across that way. What I was questioning is whether or not we wanted to add a hard requirement on zookeeper somewhere. Even Rabbit and MySQL are decisions with other options. It's entirely possible I misread the conversation of course... > On 10/31/13 10:17 AM, "Monty Taylor" <mord...@inaugust.com> wrote: > >> Sigh. >> >> Yay!!!! We've added more competing methods of complexity!!! >> >> Seriously. We now think that rabbit and zookeeper and mysql are ALL >> needed? >> >> Joshua Harlow <harlo...@yahoo-inc.com> wrote: >> >>> I'm pretty sure the cats out of the bag. >>> >>> https://github.com/openstack/requirements/blob/master/global-requirements >>> .t >>> xt#L29 >>> >>> https://kazoo.readthedocs.org/en/latest/ >>> >>> -Josh >>> >>> On 10/31/13 7:43 AM, "Monty Taylor" <mord...@inaugust.com> wrote: >>> >>>> >>>> >>>> On 10/30/2013 10:42 AM, Clint Byrum wrote: >>>>> So, recently we've had quite a long thread in gerrit regarding locking >>>>> in Heat: >>>>> >>>>> https://review.openstack.org/#/c/49440/ >>>>> >>>>> In the patch, there are two distributed lock drivers. One uses SQL, >>>>> and suffers from all the problems you might imagine a SQL based >>>>> locking >>>>> system would. It is extremely hard to detect dead lock holders, so we >>>>> end up with really long timeouts. The other is ZooKeeper. >>>>> >>>>> I'm on record as saying we're not using ZooKeeper. It is a little >>>>> embarrassing to have taken such a position without really thinking >>>>> things >>>>> through. The main reason I feel this way though, is not because >>>>> ZooKeeper >>>>> wouldn't work for locking, but because I think locking is a mistake. >>>>> >>>>> The current multi-engine paradigm has a race condition. If you have a >>>>> stack action going on, the state is held in the engine itself, and not >>>>> in the database, so if another engine starts working on another >>>>> action, >>>>> they will conflict. >>>>> >>>>> The locking paradigm is meant to prevent this. But I think this is a >>>>> huge mistake. >>>>> >>>>> The engine should store _all_ of its state in a distributed data store >>>>> of some kind. Any engine should be aware of what is already happening >>>>> with the stack from this state and act accordingly. That includes the >>>>> engine currently working on actions. When viewed through this lense, >>>>> to me, locking is a poor excuse for serializing the state of the >>>>> engine >>>>> scheduler. >>>>> >>>>> It feels like TaskFlow is the answer, with an eye for making sure >>>>> TaskFlow can be made to work with distributed state. I am not well >>>>> versed on TaskFlow's details though, so I may be wrong. It worries me >>>>> that TaskFlow has existed a while and doesn't seem to be solving real >>>>> problems, but maybe I'm wrong and it is actually in use already. >>>>> >>>>> Anyway, as a band-aid, we may _have_ to do locking. For that, >>>>> ZooKeeper >>>>> has some real advantages over using the database. But there is >>>>> hesitance >>>>> because it is not widely supported in OpenStack. What say you, >>>>> OpenStack >>>>> community? Should we keep ZooKeeper out of our.. zoo? >>>> >>>> Yes. I'm strongly opposed to ZooKeeper finding its way into the already >>>> complex pile of things we use. >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
