Open Stack

Hi All,

As part of Liberty spec [1] was approved with the conclusion that
nova.services data be stored and managed by respective driver backend that
is selected by the CONF.servicegroup_driver (which can be
DB/Zookeeper/Memcache).

When this spec was proposed again for Mitaka[3], the idea that has come up
is that the nova.services data will remain in nova database itself and the
servicegroup zookeeper, memcache drivers be used solely for
liveliness/up/down ness of the service. The idea being using the best of
both worlds and few operations for example getting min/max for a service id
can be quicker when done a query in DB in comparison to ZK/Memcache
backends. But ZK driver is worthwhile for state management as it minimizes
the burden on nova db to store the additional *periodic* (depending on
service_down_time) liveliness information.

Please note [4] depends on [3] and a conclusion on [3] can pave a way
forward for [4] (similarly [1] was a dependency for [2]). A detail document
[5] encompassing all the possible options by having different permutation
of various drivers (db/zk/mc). Once we have a conclusion on one of the
approach proposed in [5] will update spec [3] to reflect these changes.

So in short

*Accepted in Liberty [1] [2] :*
[1] Services information be stored in respective backend configured by
CONF.servicegroup_driver
and all the interfaces which plan to access service information go through
servicegroup layer.
[2] Add tooz specific drivers e.g. replace existing nova servicegroup
zookeeper driver with a new zookeeper driver backed by Tooz zookeeper
driver.

*Proposal for Mitaka [3][4] :*
[3] Services information be stored in nova.services (nova database) and
liveliness information be managed by CONF.servicegroup_driver
(DB/Zookeeper/Memcache)
[4] Stick to what is accepted for #2. Just that the scope will be decided
based on whether we go with #1 (as accepted for Liberty) or #3 (what is
proposed for Mitaka)


- Vilobh

[1] Servicegroup foundational refactoring for Control Plane *(Liberty)* -
https://review.openstack.org/#/c/190322/

[2] Add tooz service group driver* (Liberty)* -
https://review.openstack.org/#/c/138607/

[3] Servicegroup foundational refactoring for Control Plane *(Mitaka)* -
https://review.openstack.org/#/c/222423/

[4] Add tooz service group driver *(Mitaka) *-
https://review.openstack.org/#/c/222422/

[5] *Various options and there impact* :
https://etherpad.openstack.org/p/servicegroup-refactoring
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150923/59a71e69/attachment-0001.html>