Servicegroup foundational refactoring for Control Plane

Registered by Vilobh Meshram on 2015-05-08

At present, there are various interfaces through with services data can be manipulated - admin interface( nova-manage), extension (contrib/services.py), 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 nova.services.

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://review.openstack.org/#/c/138607/
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-May/063602.html

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 on 2016-01-15

Related branches

Sprints

Whiteboard

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

Gerrit topic: https://review.openstack.org/#q,topic:bp/servicegroup-api-control-plane,n,z

Addressed by: https://review.openstack.org/190322
    Servicegroup foundational refactoring for Control Plane

Addressed by: https://review.openstack.org/195559
    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://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Non-priority_Blueprint_Feature_Freeze and http://lists.openstack.org/pipermail/openstack-dev/2015-June/065819.html
--johnthetubaguy 15th July 2015

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

Addressed by: https://review.openstack.org/202714
    WIP : Servicegroup foundational refactoring for Control Plane

Addressed by: https://review.openstack.org/222423
    Servicegroup foundational refactoring for Control Plane

Gerrit topic: https://review.openstack.org/#q,topic:bp/tooz-for-service-groups,n,z

Addressed by: https://review.openstack.org/235637
    WIP : Servicegroup Foundational Refactoring

Addressed by: https://review.openstack.org/269929
    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://docs.openstack.org/releases/schedules/mitaka.html#m-nova-npff and http://docs.openstack.org/developer/nova/process.html#non-priority-feature-freeze
--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.