Apologies for not responding earlier, I am on vacation ATM. Responses inline.

On 10/31/2013 08:13 AM, Sandy Walsh wrote:

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

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.

The HyperV scenario is different then the heat scenario. If someone uses HyperV in Nova, they are pretty much on their own because of their choice to support a MS based virt infrastructure. HyperV is not a choice many OpenStack deployments (if any...) will make.

In the case of Heat, the "default choice" will be zookeeper, because it doesn't suffer from dead locks problem. Unfortunately these users will not recognize the problems that come with zookeeper (HA, scalability, security, documentation, different runtime environment) until it is too late to alter the previous decision that was made ("We must have zookeeper!!").

I really don't think most people will *use* Nova with HyperV even though it is optional. I do believe, however, that if zookeeper were "optional" it would become the default way to deploy Heat. This naturally leads to the Heat developers dealing with the ensuing chaos for one very specific problem that can be solved using alternative methods.

When users of OpenStack choose a db (postgres or mysql), or amqp (qpid or rabbit), the entire OpenStack community is able to respond with support, rather then one program (heat) in the hypothetical case of Zookeeper.

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?


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.

The pain is not worth the gain. A better solution would be to avoid locking all-together.

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.
And the Heat devs are the only folks with any responsibility to support it in this scenario. If we are going to bring the pain, we should share it equally between programs :)

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?

Choices are fundamental in life, and I generally disagree with limiting choices for people, including our target user base. However, I'd prefer us investigate choices that do not negatively impact one group of folks (the Heat developers and the various downstreams) in a profound way before we give up and say "too hard".

As an example of the thought processes that went on after zookeeper was proposed, heat-core devs were talking about introducing a zookeeper tempest gate for Heat. In my mind if we gate it, we support it. This leads to the natural conclusion that it must be securi-fied, HA-ified, documenti-fied, and scalei-fied). Groan.

See how one optional feature spins out of control?

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?
explained above.
What I would prefer is taskflow over AMQP, to leverage existing server
infrastructure (that has already been documented, scaled, secured, and
Same problem exists, we're just pushing the ZK decision to another service.
This model reuses the AMQP choice that the deployer has already committed to. No zookeeper is needed in this model. No extra server processes are needed. Instead we live with two server processes (db, amqp) and add a library dependency (taskflow?) that uses AMQP for distributed task flow decision making.

Clearly lighter weight.



OpenStack-dev mailing list

OpenStack-dev mailing list
OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to