Open Stack

On 11/04/2015 04:09 PM, Davanum Srinivas wrote:
> Graham,
>
> Agree. Hence the Tooz as the abstraction layer. Folks are welcome to
> write new drivers or fix existing drivers for Tooz where needed.

Yes. This is correct. We cannot grow a hard depend on a Java thing, but 
optional depends are ok - and it turns out the semantics needed from 
DLMs and DKVSs are sufficiently abstractable for it to make sense.

That said - the only usable tooz backend at the moment is zookeeper - so 
someone who cares about the not-Java use case will have to step up and 
write a consul backend. The main thing is that we allow that to happen 
and don't do things that would prevent such a thing from being written.

Reasons for making ZK the default are:

- It exists in tooz today
- It's easily installable in all the distros
- It has devstack support already

None of those three are true of consul, although none are terribly hard 
to achieve.

> On Wed, Nov 4, 2015 at 3:04 PM, Hayes, Graham <graham.hayes at hpe.com> wrote:
>> On 04/11/15 20:04, Ed Leafe wrote:
>>> On Nov 3, 2015, at 6:45 AM, Davanum Srinivas <davanum at 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.
>>>
>>>
>>> -- Ed Leafe
>>>
>>
>> I got the impression that there was *some* operators that wouldn't run
>> java.
>>
>> I do not see an issue with having ZooKeeper as the default, as long as
>> there is an alternate solution that also works for the operators that do
>> not want to use it.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>