Hi Li, Can you give a quick background on servicegroups (or links to. The spec you linked only describe the process on Nova to change from what they are using to tooz)? Also, what are the use cases and benefits of using this?
Erlon On Tue, Dec 22, 2015 at 8:49 AM, Michał Dulko <michal.du...@intel.com> wrote: > On 12/17/2015 04:49 AM, li.yuanz...@zte.com.cn wrote: > > Hi all, > > > > I'd like to start discussion on whether the servicegroup in Cinder > > is necessary. > > > > Recently, cinder can only support db driver, and doesn't have > > servicegroup concept. > > our team wants to implement the servicegroup feature using on > > tooz[1] library. Like nova[2], when the state of service is required, > > it can be got through servicegroup. > > > > Besides, due to the cinder-volume-active-active-support[3] merged, > > we think it makes the Service Group do more. > > > > Before the cinder-volume-active-active-support was proposed, Cinder > > has no concept of cluster. Therefore, we have a doubt that, if without > > cinder-volume-active-active-support, is it necessary to add feature of > > servicegroup? > > > > Any comments or suggestions? > > > > [1] > > > https://github.com/openstack/tooz/blob/master/doc/source/tutorial/group_membership.rst > > > > [2] > > > https://github.com/openstack/nova-specs/blob/master/specs/liberty/approved/service-group-using-tooz.rst > > > > [3] > > > https://github.com/openstack/cinder-specs/blob/master/specs/mitaka/cinder-volume-active-active-support.rst > > > > > > > > Best Regards, > > Janice > > Hi, > > It will not be possible to use A/A HA configuration of cinder-volume > service with LVM driver. According to latest User Survey [1] this driver > is running in 22% of deployments. ZooKeeper service groups will be still > useful there, as it will allow scheduler to know about failed > services/nodes much quicker and prevent from scheduling volumes there. > > As we have initial Tooz integration [2] already merged for locking > purposes, I think that if we'll be able to implement SG in a > non-intrusive manner (without changing the default behavior) it would be > an interesting option for some deployments. > > [1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf > [2] https://review.openstack.org/#/c/183537/ > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
