Complete "Base services" proposal

Provide rationale, split out proposal and add implementation plan.

Change-Id: I7f1e4ee0bcffd351448392c39e4cf79c24e0b0c8
This commit is contained in:
Thierry Carrez 2017-01-18 15:22:14 +01:00
parent d06c1c029b
commit fbdca57171
1 changed files with 101 additions and 40 deletions

View File

@ -3,20 +3,52 @@ Base services
=============
Definition
==========
Summary
=======
Components of OpenStack do not run in a vacuum. They leverage features present
in a number of external services to run. Some of those dependencies are local
in a number of other services to run. Some of those dependencies are local
(like a hypervisor on a compute node), while some of those are global (like
a database). "Base services" are those global services that an OpenStack
a database). "Base services" are those *global* services that an OpenStack
component can assume will be present in an "OpenStack" installation, and that
they can therefore leverage to deliver features. Components of course do not
*have to* use those, but they can.
*have to* use those, but they can assume they will be available, in case they
*want* to use them.
Analysis and options
====================
Rationale
=========
In the early days of OpenStack, we decided (without really writing it down)
that every OpenStack component could assume that a number of base services
would be available: a relational database (MySQL), a message queue (RabbitMQ),
and an AuthN/AuthZ token service (Keystone). Being able to assume that those
external services would be present encouraged components to make use of them,
and also encouraged convergence on the same set of components, reducing
operational impact.
That early decision served us well, but since then we were unable to grow
that set of base services. Some of it is due to being extra-careful not to add
new mandatory services that would impact all OpenStack deployments, some of it
is due to not defining the base services concept in the first place, and some
of it is due to the growth of OpenStack and the difficulty to make such central
decisions.
However, we still very much need to build on top of advanced base features,
like a distributed lock manager (Zookeeper?), or a secrets vault (Barbican?).
Rather than making the hard decision, we work around their absence in every
project, badly emulating those features using what we have, or reinventing
them locally. In the name of containing overall operational complexity, we
make every component more monolithic and less efficient, increasing operational
complexity.
Recognizing "base services" for what they are, and having a path to grow the
set of those base services, is therefore essential to the continued growth
and relevance of OpenStack. This is what this proposal is addressing.
Detailed analysis
=================
The trade-off with base services
--------------------------------
@ -38,28 +70,6 @@ secure as its weakest link, additional services have the potential to
adversely impact the system if they are not up to par with the rest of the
base services.
Current base services
---------------------
There are currently three "base services" that components can assume will be
present in an "OpenStack" installation:
* An oslo.db-compatible database (MySQL)
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 (RabbitMQ)
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.
* Keystone
OpenStack Keystone handles AuthN/AuthZ for OpenStack components.
Deployments can assume that Keystone will be present to perform that role.
Narrow or wide base services
----------------------------
@ -84,15 +94,66 @@ limited set of options. That gives deployers some choice while keeping
development cost/distraction under control.
Proposed process for addition of new base services
--------------------------------------------------
Proposal
========
This proposal is limited to defining the concept, specifying the current list
and writing a process to grow the list. It is specifically *not* proposing
any specific addition.
Definition of base services
---------------------------
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
-----------------------------
There are currently three base services that components can assume will be
present in any "OpenStack" installation:
* An oslo.db-compatible database (MySQL)
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 (RabbitMQ)
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.
* Keystone
OpenStack Keystone handles AuthN/AuthZ for OpenStack components.
Deployments can assume that Keystone will be present to perform that role.
The list of available base services will be maintained as a living TC
governance document under the openstack/governance repository (and
published on the https://governance.openstack.org/tc website).
Process for addition of new base services
-----------------------------------------
The decision to add new base services to OpenStack impacts all of OpenStack,
therefore such additions should be ultimately approved by the OpenStack
Technical Committee. When new base services are proposed, the Architecture WG
provides a thorough analysis to weigh the trade-off mentioned above. Based on
that analysis, the Architecture WG produces a recommendation to the TC (which
the TC is free to follow or ignore).
Implementation
==============
Assignee: Thierry Carrez (ttx)
Work items
----------
* Propose concept definition and current list to the governance repository
* Get Technical Committee approval on those documents
* Add mentions of "base services" in the Project Team Guide
The decision to add new base services to OpenStack impacts all of OpenStack.
The Architecture WG therefore suggests that such additions are ultimately
approved by the OpenStack Technical Committee. When new base services are
proposed, the Architecture WG proposes to provide a thorough analysis to
weigh the trade-off mentioned above. Based on that analysis, the Architecture
WG will make a recommendation to the TC (which the TC is free to follow or
ignore). The list of available base services will be maintained as a TC
governance document under the openstack/governance repository (and published
on the governance.openstack.org website).