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
57 lines
2.2 KiB
ReStructuredText
57 lines
2.2 KiB
ReStructuredText
=============
|
|
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.
|