<font size=2 face="sans-serif">Right.. Maybe this was not a good suggestion.
The thought was that in small-scale deployments, requiring ZK might be
a significant management overhead. While for large-scale ones it would
be more acceptable. So, the question is how to make this work reasonably
well on small scale without ZK, and enable flexible scale-up/out by adding
ZK.</font>
<br><font size=2 face="sans-serif">Maybe assume one conductor that would
serialize (some of the) tasks and keep enough state in DB for failure recovery
if there is no ZK, and do it in a more scalable & resilient manner
if ZK is present.</font>
<br>
<br><font size=2 face="sans-serif">Alex<br>
</font>
<br>
<br><tt><font size=2>Joshua Harlow <harlowja@yahoo-inc.com> wrote
on 02/05/2013 08:50:29 PM:<br>
<br>
> From: Joshua Harlow <harlowja@yahoo-inc.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-<br>
> dev@lists.openstack.org>, Alex Glikson/Haifa/IBM@IBMIL, </font></tt>
<br><tt><font size=2>> Date: 02/05/2013 08:50 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] Nova workflow management
update</font></tt>
<br><tt><font size=2>> <br>
> So this brings up an interesting issue, the reason ZK exists or <br>
> partially exists is that something like ZK api's over DB weren't <br>
> really possible. Or that’s what I thought :-P</font></tt>
<br><tt><font size=2>> <br>
> Or they weren't possible in a accurate and provable accurate manner.<br>
> So spending time creating apis that 'sorta' work with DB's but <br>
> really don't (since ZK wouldn't exist if it was possible) does seem
<br>
> sorta awkward. I thought most cloud providers are already using <br>
> zookeeper, for these exact same reasons, and deploying it now-adays
<br>
> is pretty simple… </font></tt>
<br><tt><font size=2>> <br>
> I just worry about providing API's that really don't work correctly
<br>
> with DB's that will cause more bugs (since certain problems just <br>
> can't be done with a DB, or at least any of the DBs that I have <br>
> used, maybe db2 can, idk) that we will have to say 'oh ya we know
<br>
> that doesn't work with a DB'. But maybe that is a compromise that
we<br>
> have to make and is a evolutionary process where the amount of bugs
<br>
> that will be caused by DB impls will eventually just cause people
to<br>
> move to the more attractive ZK backend… Its also sorta concerning
<br>
> that those types of DB like bugs will be harder than heck to trace
<br>
> down, but that might be a different issue that we can resolve.</font></tt>
<br><tt><font size=2>> <br>
> From: Alex Glikson <GLIKSON@il.ibm.com><br>
> Reply-To: OpenStack Development Mailing List <openstack-<br>
> dev@lists.openstack.org><br>
> Date: Thursday, May 2, 2013 7:53 AM<br>
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org><br>
> Subject: Re: [openstack-dev] Nova workflow management update</font></tt>
<br><tt><font size=2>> <br>
> Changbin Liu <changbin.liu@gmail.com> wrote on 02/05/2013 05:32:05
PM:<br>
> <br>
> > Subject: Re: [openstack-dev] Nova workflow management update
<br>
> > <br>
> > Hi Joshua,  <br>
> > <br>
> > Just to share some thoughts: <br>
> [...]<br>
> <br>
> Using ZK makes a lot of sense.. The problem is that making ZooKeeper<br>
> a mandatory component to support even basic workflow management <br>
> might be an issue. So, the approach which seems to make most sense
<br>
> is to define abstract internal interfaces for the various <br>
> capabilities that ZK can provide (distributed locking, leader <br>
> election, etc), and then have one or more implementations (one of
<br>
> which might be based on ZK). This is the approach that has been <br>
> taken for the membership service (service group monitoring APIs) --
<br>
> introducing the flexibility to use ZK backend, but keeping the <br>
> default to be DB-backed.<br>
> <br>
> Regards, <br>
> Alex <br>
> <br>
> P.S. thinking about this.. would it be possible to implement ZK APIs<br>
> over a DB? with some limitations, perhaps..</font></tt>