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/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