summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--active/base-services.rst141
1 files changed, 101 insertions, 40 deletions
diff --git a/active/base-services.rst b/active/base-services.rst
index 61d417c..97d4f20 100644
--- a/active/base-services.rst
+++ b/active/base-services.rst
@@ -3,20 +3,52 @@ Base services
3============= 3=============
4 4
5 5
6Definition 6Summary
7========== 7=======
8 8
9Components of OpenStack do not run in a vacuum. They leverage features present 9Components of OpenStack do not run in a vacuum. They leverage features present
10in a number of external services to run. Some of those dependencies are local 10in a number of other services to run. Some of those dependencies are local
11(like a hypervisor on a compute node), while some of those are global (like 11(like a hypervisor on a compute node), while some of those are global (like
12a database). "Base services" are those global services that an OpenStack 12a database). "Base services" are those *global* services that an OpenStack
13component can assume will be present in an "OpenStack" installation, and that 13component can assume will be present in an "OpenStack" installation, and that
14they can therefore leverage to deliver features. Components of course do not 14they can therefore leverage to deliver features. Components of course do not
15*have to* use those, but they can. 15*have to* use those, but they can assume they will be available, in case they
16*want* to use them.
16 17
17 18
18Analysis and options 19Rationale
19==================== 20=========
21
22In the early days of OpenStack, we decided (without really writing it down)
23that every OpenStack component could assume that a number of base services
24would be available: a relational database (MySQL), a message queue (RabbitMQ),
25and an AuthN/AuthZ token service (Keystone). Being able to assume that those
26external services would be present encouraged components to make use of them,
27and also encouraged convergence on the same set of components, reducing
28operational impact.
29
30That early decision served us well, but since then we were unable to grow
31that set of base services. Some of it is due to being extra-careful not to add
32new mandatory services that would impact all OpenStack deployments, some of it
33is due to not defining the base services concept in the first place, and some
34of it is due to the growth of OpenStack and the difficulty to make such central
35decisions.
36
37However, we still very much need to build on top of advanced base features,
38like a distributed lock manager (Zookeeper?), or a secrets vault (Barbican?).
39Rather than making the hard decision, we work around their absence in every
40project, badly emulating those features using what we have, or reinventing
41them locally. In the name of containing overall operational complexity, we
42make every component more monolithic and less efficient, increasing operational
43complexity.
44
45Recognizing "base services" for what they are, and having a path to grow the
46set of those base services, is therefore essential to the continued growth
47and relevance of OpenStack. This is what this proposal is addressing.
48
49
50Detailed analysis
51=================
20 52
21The trade-off with base services 53The trade-off with base services
22-------------------------------- 54--------------------------------
@@ -38,28 +70,6 @@ secure as its weakest link, additional services have the potential to
38adversely impact the system if they are not up to par with the rest of the 70adversely impact the system if they are not up to par with the rest of the
39base services. 71base services.
40 72
41
42Current base services
43---------------------
44
45There are currently three "base services" that components can assume will be
46present in an "OpenStack" installation:
47
48* An oslo.db-compatible database (MySQL)
49 OpenStack components store data in a database, using oslo.db as an
50 indirection layer. While most OpenStack deployments use MySQL, other
51 databases are supported.
52
53* An oslo.messaging-compatible message queue (RabbitMQ)
54 Some inter-process and inter-service communication in OpenStack
55 components is accomplished using message queues, through oslo.messaging
56 as an indirection layer. While most OpenStack deployments use RabbitMQ,
57 other message queues are supported.
58
59* Keystone
60 OpenStack Keystone handles AuthN/AuthZ for OpenStack components.
61 Deployments can assume that Keystone will be present to perform that role.
62
63Narrow or wide base services 73Narrow or wide base services
64---------------------------- 74----------------------------
65 75
@@ -84,15 +94,66 @@ limited set of options. That gives deployers some choice while keeping
84development cost/distraction under control. 94development cost/distraction under control.
85 95
86 96
87Proposed process for addition of new base services 97Proposal
88-------------------------------------------------- 98========
99
100This proposal is limited to defining the concept, specifying the current list
101and writing a process to grow the list. It is specifically *not* proposing
102any specific addition.
103
104Definition of base services
105---------------------------
106
107Base services are services that OpenStack components can assume will be
108present in any OpenStack deployment. OpenStack components may therefore
109leverage advanced features exposed by those base services without fear of
110increasing the overall operational complexity for OpenStack deployers.
111
112Current list of base services
113-----------------------------
114
115There are currently three base services that components can assume will be
116present in any "OpenStack" installation:
117
118* An oslo.db-compatible database (MySQL)
119 OpenStack components store data in a database, using oslo.db as an
120 indirection layer. While most OpenStack deployments use MySQL, other
121 databases are supported.
122
123* An oslo.messaging-compatible message queue (RabbitMQ)
124 Some inter-process and inter-service communication in OpenStack
125 components is accomplished using message queues, through oslo.messaging
126 as an indirection layer. While most OpenStack deployments use RabbitMQ,
127 other message queues are supported.
128
129* Keystone
130 OpenStack Keystone handles AuthN/AuthZ for OpenStack components.
131 Deployments can assume that Keystone will be present to perform that role.
132
133The list of available base services will be maintained as a living TC
134governance document under the openstack/governance repository (and
135published on the https://governance.openstack.org/tc website).
136
137Process for addition of new base services
138-----------------------------------------
139
140The decision to add new base services to OpenStack impacts all of OpenStack,
141therefore such additions should be ultimately approved by the OpenStack
142Technical Committee. When new base services are proposed, the Architecture WG
143provides a thorough analysis to weigh the trade-off mentioned above. Based on
144that analysis, the Architecture WG produces a recommendation to the TC (which
145the TC is free to follow or ignore).
146
147
148Implementation
149==============
150
151Assignee: Thierry Carrez (ttx)
152
153Work items
154----------
155
156 * Propose concept definition and current list to the governance repository
157 * Get Technical Committee approval on those documents
158 * Add mentions of "base services" in the Project Team Guide
89 159
90The decision to add new base services to OpenStack impacts all of OpenStack.
91The Architecture WG therefore suggests that such additions are ultimately
92approved by the OpenStack Technical Committee. When new base services are
93proposed, the Architecture WG proposes to provide a thorough analysis to
94weigh the trade-off mentioned above. Based on that analysis, the Architecture
95WG will make a recommendation to the TC (which the TC is free to follow or
96ignore). The list of available base services will be maintained as a TC
97governance document under the openstack/governance repository (and published
98on the governance.openstack.org website).