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.ha...@hpe.com> wrote:
On 04/11/15 20:04, 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.


-- 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-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

Reply via email to