Sandy,
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
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.
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?
-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.
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
HA-ified).
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.
Regards,
-steve
Regards
-steve
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
