Open Stack

Agreed, 

I don't think we should enforce a hard requirement for the same reason we
should avoid zookeeper.

To me they are the same, saying 'no ZK' is the same as saying 'only mysql
or rabbitmq'...

Both not so open.

On 10/31/13 11:04 AM, "Monty Taylor" <mordred at inaugust.com> wrote:

>
>
>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" <mordred at 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 <harlowja at yahoo-inc.com> wrote:
>>>
>>>> I'm pretty sure the cats out of the bag.
>>>>
>>>> 
>>>>https://github.com/openstack/requirements/blob/master/global-requiremen
>>>>ts
>>>> .t
>>>> xt#L29
>>>>
>>>> https://kazoo.readthedocs.org/en/latest/
>>>>
>>>> -Josh
>>>>
>>>> On 10/31/13 7:43 AM, "Monty Taylor" <mordred at 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 at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>> 
>>