Open Stack

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