<div dir="ltr"><font face="georgia, serif">Hi All,</font><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">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.<span style="color:rgb(0,0,0);font-size:13.3333px">servicegroup_driver (which can be DB/Zookeeper/Memcache).</span></font></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></font></div><div><font face="georgia, serif"><font color="#000000"><span style="font-size:13.3333px">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.</span></font></font></div><div><font face="georgia, serif"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></font></div><div><font face="georgia, serif">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.</font></div><div><font face="georgia, serif"><br></font></div><div><font face="georgia, serif">So in short</font></div><div><font face="georgia, serif"><br></font></div><div><b><font face="georgia, serif">Accepted in Liberty [1] [2] :</font></b></div><div><font face="georgia, serif">[1] Services information be stored in respective backend configured by CONF.<span style="color:rgb(0,0,0);font-size:13.3333px">servicegroup_driver and all the interfaces which plan to access service information go through servicegroup layer.</span></font></div><div><span style="color:rgb(0,0,0);font-size:13.3333px"><font face="georgia, serif">[2] Add tooz specific drivers e.g. replace existing nova servicegroup zookeeper driver with a new zookeeper driver backed by Tooz zookeeper driver.</font></span></div><div><span style="color:rgb(0,0,0);font-size:13.3333px"><font face="georgia, serif"><br></font></span></div><div><span style="color:rgb(0,0,0);font-size:13.3333px"><b><font face="georgia, serif">Proposal for Mitaka [3][4] :</font></b></span></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px">[3] </span>Services information be stored in nova.services (nova database) and liveliness information be managed by CONF.<font color="#000000"><span style="font-size:13.3333px">servicegroup_driver (DB/Zookeeper/Memcache)</span></font></font></div><div><span style="color:rgb(0,0,0);font-size:13.3333px"><font face="georgia, serif">[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)</font></span></div><div><b><font face="georgia, serif"><br></font></b></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></font></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px">- Vilobh</span></font></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></font></div><div><font face="georgia, serif"><span style="color:rgb(0,0,0);font-size:13.3333px">[1] </span><span style="color:rgb(0,0,0);font-size:9pt">Servicegroup foundational refactoring for Control Plane <b>(Liberty)</b> - </span><span style="font-size:13.3333px;color:rgb(0,0,0)"><a href="https://review.openstack.org/#/c/190322/">https://review.openstack.org/#/c/190322/</a></span></font></div><div><font color="#000000" face="georgia, serif"><span style="font-size:13.3333px"><br></span></font></div><div><font face="georgia, serif"><font color="#000000"><span style="font-size:13.3333px">[2] </span></font><span style="color:rgb(0,0,0);font-size:9pt">Add tooz service group driver<b> (Liberty)</b> - </span><font color="#000000"><span style="font-size:12px"><a href="https://review.openstack.org/#/c/138607/">https://review.openstack.org/#/c/138607/</a></span></font></font></div><div><font face="georgia, serif"><font color="#000000"><span style="font-size:12px"><br></span></font></font></div><div><font face="georgia, serif"><font color="#000000"><span style="font-size:12px">[3] </span></font><span style="color:rgb(0,0,0);font-size:12px">Servicegroup foundational refactoring for Control Plane <b>(Mitaka)</b> - </span><span style="font-size:12px;color:rgb(0,0,0)"><a href="https://review.openstack.org/#/c/222423/">https://review.openstack.org/#/c/222423/</a></span></font></div><div><span style="font-size:12px;color:rgb(0,0,0)"><font face="georgia, serif"><br></font></span></div><div><font face="georgia, serif"><span style="font-size:12px;color:rgb(0,0,0)">[4] </span><span style="color:rgb(0,0,0);font-size:12px">Add tooz service group driver <b>(Mitaka) </b>- </span><span style="font-size:12px;color:rgb(0,0,0)"><a href="https://review.openstack.org/#/c/222422/">https://review.openstack.org/#/c/222422/</a></span></font></div><div><span style="font-size:12px;color:rgb(0,0,0)"><font face="georgia, serif"><br></font></span></div><div><font face="georgia, serif"><span style="font-size:12px;color:rgb(0,0,0)">[5] <b>Various options and there impact</b> : </span><a href="https://etherpad.openstack.org/p/servicegroup-refactoring" target="_blank">https://etherpad.openstack.org/p/servicegroup-refactoring</a></font></div></div>