<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I think we are onto something here, and we might be able to create a set of core primitives that might be ok for small-scale deployments where the acceptable error rate (due to the lack of correctness) might be ok?</div>
<div><br>
</div>
<div>Something like it might be possible, just wonder if the going both paths causes more problems than it solves, not sure myself really.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Alex Glikson <<a href="mailto:GLIKSON@il.ibm.com">GLIKSON@il.ibm.com</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, May 2, 2013 11:27 AM<br>
<span style="font-weight:bold">To: </span>Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
<span style="font-weight:bold">Cc: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] Nova workflow management update<br>
</div>
<div><br>
</div>
<div>
<div><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 <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote on 02/05/2013 08:50:29 PM:<br>
<br>
> From: Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>></font></tt>
<br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-<br>
> <a href="mailto:dev@lists.openstack.org">dev@lists.openstack.org</a>>, 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 <<a href="mailto:GLIKSON@il.ibm.com">GLIKSON@il.ibm.com</a>><br>
> Reply-To: OpenStack Development Mailing List <openstack-<br>
> <a href="mailto:dev@lists.openstack.org">dev@lists.openstack.org</a>><br>
> Date: Thursday, May 2, 2013 7:53 AM<br>
> To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] Nova workflow management update</font></tt> <br>
<tt><font size="2">> <br>
> Changbin Liu <<a href="mailto:changbin.liu@gmail.com">changbin.liu@gmail.com</a>> 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></div>
</div>
</span>
</body>
</html>