Browse Source

Define "base services" in OpenStack

Introduce the concept of "base services", which are components
that all OpenStack components can assume will be present in an
OpenStack installation, and which features they can therefore
freely leverage if they want to.

Change-Id: I386069aa1f1ceb4c34101f3d4f0282edbbe4a661
changes/49/406049/2
Thierry Carrez 2 years ago
parent
commit
be3afcb49d
1 changed files with 98 additions and 0 deletions
  1. 98
    0
      proposals/base-services.rst

+ 98
- 0
proposals/base-services.rst View File

@@ -0,0 +1,98 @@
1
+=============
2
+Base services
3
+=============
4
+
5
+
6
+Definition
7
+==========
8
+
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
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
13
+component can assume will be present in an "OpenStack" installation, and that
14
+they can therefore leverage to deliver features. Components of course do not
15
+*have to* use those, but they can.
16
+
17
+
18
+Analysis and options
19
+====================
20
+
21
+The trade-off with base services
22
+--------------------------------
23
+
24
+Leveraging features from a base service (rather than working around
25
+limitations or badly reinventing the wheel) is key to reaching acceptable
26
+levels of stability, performance and scaling. There is therefore a natural
27
+tendancy for developers to add the right tool for the right job whenever
28
+it's needed. However, since they will likely have to be deployed in most
29
+OpenStack deployments, base services increase the operational complexity
30
+of running OpenStack.
31
+
32
+So it is very important to balance those two sides and very conservatively
33
+consider proposed additions to the base services list, especially when those
34
+additions introduce a whole new class of operational challenges. It is also
35
+very important to consider how performant, stable and secure the new
36
+dependency is: since a complex system is only as performant, stable or
37
+secure as its weakest link, additional services have the potential to
38
+adversely impact the system if they are not up to par with the rest of the
39
+base services.
40
+
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
+Narrow or wide base services
64
+----------------------------
65
+
66
+There are two possible approaches with base services. They can be narrow,
67
+and focus on a particular implementation. Or they can be wide, using an
68
+indirection layer (generally an interface library) below which multiple
69
+competing solutions could be plugged. With the narrow approach, you can
70
+take advantage of the unique features of a particular solution, you don't
71
+have to limit yourself to some common denominator between multiple solutions.
72
+It is also less costly from a development standpoint, with only one interface
73
+layer to maintain and test. The wide approach is more operator-friendly: it
74
+lets deployers choose their preferred underlying implementation.
75
+
76
+Historically, OpenStack has opted for the wide approach, generally supporting
77
+as many underlying solutions as possible. Lately, a "narrow wide" approach
78
+was followed: while we still use indirection layers and support multiple
79
+options, we try to limit the number of options available. Only tested,
80
+featureful options are supported in mainline code, and only to the point
81
+where they provide useful choice. As a result of this, untested or
82
+non-functional or useless options are getting pruned, to focus on a
83
+limited set of options. That gives deployers some choice while keeping
84
+development cost/distraction under control.
85
+
86
+
87
+Proposed process for addition of new base services
88
+--------------------------------------------------
89
+
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