<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>So this brings up an interesting issue, the reason ZK exists or partially exists is that something like ZK api's over DB weren't really possible. Or that’s what I thought :-P</div>
<div><br>
</div>
<div>Or they weren't possible in a accurate and provable accurate manner. So spending time creating apis that 'sorta' work with DB's but really don't (since ZK wouldn't exist if it was possible) does seem sorta awkward. I thought most cloud providers are already
using zookeeper, for these exact same reasons, and deploying it now-adays is pretty simple… </div>
<div><br>
</div>
<div>I just worry about providing API's that really don't work correctly with DB's that will cause more bugs (since certain problems just can't be done with a DB, or at least any of the DBs that I have used, maybe db2 can, idk) that we will have to say 'oh
ya we know that doesn't work with a DB'. But maybe that is a compromise that we have to make and is a evolutionary process where the amount of bugs that will be caused by DB impls will eventually just cause people to move to the more attractive ZK backend…
Its also sorta concerning that those types of DB like bugs will be harder than heck to trace down, but that might be a different issue that we can resolve.</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">Reply-To: </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">Date: </span>Thursday, May 2, 2013 7:53 AM<br>
<span style="font-weight:bold">To: </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><tt><font size="2">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</font></tt> <br>
<tt><font size="2">> <br>
> Hi Joshua, </font></tt> <br>
<tt><font size="2">> <br>
> Just to share some thoughts:</font></tt> <br>
<tt><font size="2">[...]<br>
</font></tt><br>
<tt><font size="2">Using ZK makes a lot of sense.. The problem is that making ZooKeeper a mandatory component to support even basic workflow management might be an issue. So, the approach which seems to make most sense is to define abstract internal interfaces
for the various capabilities that ZK can provide (distributed locking, leader election, etc), and then have one or more implementations (one of which might be based on ZK). This is the approach that has been taken for the membership service (service group
monitoring APIs) -- introducing the flexibility to use ZK backend, but keeping the default to be DB-backed.</font></tt><br>
<br>
<tt><font size="2">Regards,</font></tt> <br>
<tt><font size="2">Alex</font></tt> <br>
<br>
<tt><font size="2">P.S. thinking about this.. would it be possible to implement ZK APIs over a DB? with some limitations, perhaps..</font></tt></div>
</div>
</span>
</body>
</html>