Servicegroup foundational refactoring for Control Plane

Registered by Vilobh Meshram

At present, there are various interfaces through with services data can be manipulated - admin interface( nova-manage), extension (contrib/, servicegroup API layer. Having different interfaces to manipulate the source of truth can lead to severe data inconsistency for something as useful as stored in

For example, at present even though there are multiple servicegroup drivers in nova only DB driver can be considered as a standalone driver and is the only one actively used. Zookeeper servicegroup driver is broken and Memcache driver relies on DB driver for data stored in Please refer to [1] for details. Lets say an operator uses Zookeeper to store servicegroup information so the servicegroup API will act on the services data stored in Zookeeper( to check the liveliness of the service, etc) whereas the admin interface (nova-manage) will manipulate the DB( leading to data inconsistency. The ML thread [2] explains the depth till which this is broken and urgently needs to be fixed. Various issues/specs mentioned in [2] try to patch it but with this blueprint/spec we will try to target the root cause to have a single source of truth for services data and using same API for control plane interface who update/modify the services data.

In short,

1. The proposal is to make sure all the interfaces which manipulate the services data/information should go through the servicegroup API layer for data consistency and solve many of the problems mentioned in [2] that we are seeing at present.


Blueprint information

John Garbutt
Vilobh Meshram
Needs approval
Vilobh Meshram
Pending Approval
Series goal:
Milestone target:
Started by
John Garbutt

Related branches



Please not this will need a spec. --johnthetubaguy 9th June 2015

Gerrit topic:,topic:bp/servicegroup-api-control-plane,n,z

Addressed by:
    Servicegroup foundational refactoring for Control Plane

Addressed by:
    Remove priority for Servicegroup API control plane spec

Please note this blueprint will delayed until the M release if it is not in the NeedsCodeReview state (with all the code up for review) before July 16th, and merged by July 30th. We expect to re-open master for the M release in September. For more information, please see: and
--johnthetubaguy 15th July 2015

Unapproved for liberty due to the Non-Priority Feature Proposal Freeze. --johnthetubaguy 16th July 2015

Addressed by:
    WIP : Servicegroup foundational refactoring for Control Plane

Addressed by:
    Servicegroup foundational refactoring for Control Plane

Gerrit topic:,topic:bp/tooz-for-service-groups,n,z

Addressed by:
    WIP : Servicegroup Foundational Refactoring

Addressed by:
    ServiceGroup Refactoring: Add is_up to Service Obj

Sorry, we have now hit the Non-Priority Feature Freeze for Mitaka. For more details please see: and
--johnthetubaguy 2016.02.08


Work Items

Work items:
Gather all (as many as possible) known service group/db service table using locations: INPROGRESS
Choose the path forward with regards to service groups + figure out ideal/desired service group API: TODO
Plan strategy to move all known service group/db service table using locations to service group API: TODO
Implement ideal/desired service group API: TODO
Move/deprecate all other db service table usage to API: TODO
Profit: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.