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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
