Servicegroup foundational refactoring for Control Plane
At present, there are various interfaces through with services data can be manipulated - admin interface( nova-manage), extension (contrib/
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 nova.services. 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(nova.services) 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.
[1] https:/
[2] http://
Blueprint information
- Status:
- Started
- Approver:
- John Garbutt
- Priority:
- Low
- Drafter:
- Vilobh Meshram
- Direction:
- Needs approval
- Assignee:
- Vilobh Meshram
- Definition:
- Pending Approval
- Series goal:
- None
- Implementation:
-
Blocked
- Milestone target:
- None
- Started by
- John Garbutt
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Please not this will need a spec. --johnthetubaguy 9th June 2015
Gerrit topic: https:/
Addressed by: https:/
Servicegroup foundational refactoring for Control Plane
Addressed by: https:/
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: https:/
--johnthetubaguy 15th July 2015
Unapproved for liberty due to the Non-Priority Feature Proposal Freeze. --johnthetubaguy 16th July 2015
Addressed by: https:/
WIP : Servicegroup foundational refactoring for Control Plane
Addressed by: https:/
Servicegroup foundational refactoring for Control Plane
Gerrit topic: https:/
Addressed by: https:/
WIP : Servicegroup Foundational Refactoring
Addressed by: https:/
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: http://
--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.