Complete "Base services" proposal
Provide rationale, split out proposal and add implementation plan. Change-Id: I7f1e4ee0bcffd351448392c39e4cf79c24e0b0c8
This commit is contained in:
parent
d06c1c029b
commit
fbdca57171
|
@ -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).
|
||||
|
|
Loading…
Reference in New Issue