Open Stack

On 10/30/2013 08:08 PM, Steven Dake wrote:
> 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.

But, that's the nature of every openstack project. I don't support
HyperV in Nova or HBase in Ceilometer. The implementers deal with that
support. I can help guide someone to those people but have no intentions
of standing up those environments.

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

Yes, that's why we would use it. Same goes for rabbit and mysql.

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

Why do other services need to agree on adopting ZK? If some Heat users
need it, they can use it. Nova shouldn't care.

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

Yes, there probably are, and alternatives are good. But, as others have
attested, ZK is tried and true. Why not support it also?

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

Why, if it's a plugin?

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

Same problem exists, we're just pushing the ZK decision to another service.

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