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