Browse Source

Complete "Base services" proposal

Provide rationale, split out proposal and add implementation plan.

Change-Id: I7f1e4ee0bcffd351448392c39e4cf79c24e0b0c8
changes/57/421957/2
Thierry Carrez 2 years ago
parent
commit
fbdca57171
1 changed files with 101 additions and 40 deletions
  1. 101
    40
      active/base-services.rst

+ 101
- 40
active/base-services.rst View File

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

Loading…
Cancel
Save