Open Stack

On 10/30/2013 12:20 PM, Sandy Walsh wrote:
>
> On 10/30/2013 03:10 PM, Steven Dake wrote:
>> I will -2 any patch that adds zookeeper as a dependency to Heat.
> Certainly any distributed locking solution should be plugin based and
> optional. Just as a database-oriented solution could be the default plugin.
Sandy,

Even if it is optional, some percentage of the userbase will enable it 
and expect the Heat community to debug and support it.
> Re: the Java issue, we already have optional components in other
> languages. I know Java is a different league of pain, but if it's an
> optional component and left as a choice of the deployer, should we care?
>
> -S
>
> PS> As an aside, what are your issues with ZK?
>


I realize zookeeper exists for a reason.  But unfortunately Zookeeper is 
a server, rather then an in-process library.  This means someone needs 
to figure out how to document, scale, secure, and provide high 
availability for this component.  This is extremely challenging for the 
two server infrastructure components OpenStack server processes depend 
on today (AMQP, SQL).  If the entire OpenStack community saw value in 
biting the bullet and accepting zookeeper as a dependency and taking on 
this work, I might be more ameniable.  What we are talking about in the 
review, however, is that the Heat team bite that bullet, which is a big 
addition to the scope of work we already execute for the ability to gain 
a distributed lock.  I would expect there are simpler approaches to 
solve the problem without dragging the baggage of a new server component 
into the OpenStack deployment.

Using zookeeper as is suggested in the review is far different then the 
way Nova uses Zookeeper.  With the Nova use case, Nova still operates 
just dandy without zookeeper.  With zookeeper in the Heat usecase, it 
essentially becomes the default way people are expected to deploy Heat.

What I would prefer is taskflow over AMQP, to leverage existing server 
infrastructure (that has already been documented, scaled, secured, and 
HA-ified).

Regards
-steve

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev