9ad8f55ce8
There have been a lot of discussions around scenarios like distributed locks, storing additional configuration information and coordinating service liveness checks without using a database etc. Example: http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78214 http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#113941 http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#113885 So at the Boston Summit Forum, we had a session on a specific proposal to consider Etcd 3.x for such scenarios: https://etherpad.openstack.org/p/BOS-etcd-base-service There was consensus in the room based on which a bunch of work was done in tooz, devstack etc after thorough research on the options available for both eventlet and non-eventlet based services. The consensus grew around folks using oslo library like tooz or if they choose, they can directly use etcd using python client libraries like etcd3 (for non-eventlet scenarios) and etcd3gw (for eventlet based scenarios). We should be using the v3 APIs using the etcd 3.1.x versions to avoid migration issues from the older v2 APIs. Change-Id: Id6dd2a8fffd50dca8f0de05def20d31bf9c61717
2.2 KiB
Base services
Definition
Base services are services that OpenStack components can assume will be present in any OpenStack deployment. OpenStack components may therefore leverage advanced features exposed by those base services without fear of increasing the overall operational complexity for OpenStack deployers.
Current list of base services
- An oslo.db-compatible database
-
OpenStack components store data in a database, using oslo.db as an indirection layer. While most OpenStack deployments use MySQL, other databases are supported.
- An oslo.messaging-compatible message queue
-
Some inter-process and inter-service communication in OpenStack components is accomplished using message queues through oslo.messaging as an indirection layer. While most OpenStack deployments use RabbitMQ, other message queues are supported.
- Etcd
-
OpenStack components may use Etcd, a distributed reliable key-value store for distributed key locking, storing configuration, keeping track of service live-ness and other scenarios.
- Keystone
-
Keystone handles AuthN/AuthZ for OpenStack components. Deployments can assume that Keystone will be present to perform that role.
Process for addition or removal
Leveraging features from a base service (rather than working around limitations or badly reinventing the wheel) is key to reaching acceptable levels of stability, performance and scaling. However, since they will likely have to be deployed in most OpenStack deployments, base services increase the operational complexity of running OpenStack. It is therefore very important to balance those two sides and conservatively consider proposed additions to the base services list, especially when those additions introduce a whole new class of operational challenges.
Once services start to make use of advanced features in a base service, it is difficult to remove it from the list and make it a specific dependency instead. Removals from the base service list should therefore be a rare and carefully considered event.
Proposed modifications to this document require a formal vote from the Technical Committee membership.