summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThierry Carrez <thierry@openstack.org>2016-12-02 11:46:37 +0100
committerThierry Carrez <thierry@openstack.org>2016-12-09 13:53:29 +0100
commitbe3afcb49db0833ad72b80b2bda5dc1c48cccdba (patch)
tree9b65bf23423c6ec1bd0f99da3b1f65dbeedbc37c
parent771d05ab8ca28da3ab7c498bef9568e02fdf9906 (diff)
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
Notes
Notes (review): Code-Review+1: Chris Dent <cdent@anticdent.org> Code-Review+2: Clint 'SpamapS' Byrum <clint@fewbar.com> Workflow+1: Clint 'SpamapS' Byrum <clint@fewbar.com> Verified+2: Jenkins Submitted-by: Jenkins Submitted-at: Thu, 15 Dec 2016 22:22:24 +0000 Reviewed-on: https://review.openstack.org/406049 Project: openstack/arch-wg Branch: refs/heads/master
-rw-r--r--proposals/base-services.rst98
1 files changed, 98 insertions, 0 deletions
diff --git a/proposals/base-services.rst b/proposals/base-services.rst
new file mode 100644
index 0000000..61d417c
--- /dev/null
+++ b/proposals/base-services.rst
@@ -0,0 +1,98 @@
1=============
2Base services
3=============
4
5
6Definition
7==========
8
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
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
13component can assume will be present in an "OpenStack" installation, and that
14they can therefore leverage to deliver features. Components of course do not
15*have to* use those, but they can.
16
17
18Analysis and options
19====================
20
21The trade-off with base services
22--------------------------------
23
24Leveraging features from a base service (rather than working around
25limitations or badly reinventing the wheel) is key to reaching acceptable
26levels of stability, performance and scaling. There is therefore a natural
27tendancy for developers to add the right tool for the right job whenever
28it's needed. However, since they will likely have to be deployed in most
29OpenStack deployments, base services increase the operational complexity
30of running OpenStack.
31
32So it is very important to balance those two sides and very conservatively
33consider proposed additions to the base services list, especially when those
34additions introduce a whole new class of operational challenges. It is also
35very important to consider how performant, stable and secure the new
36dependency is: since a complex system is only as performant, stable or
37secure 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
39base services.
40
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
64----------------------------
65
66There are two possible approaches with base services. They can be narrow,
67and focus on a particular implementation. Or they can be wide, using an
68indirection layer (generally an interface library) below which multiple
69competing solutions could be plugged. With the narrow approach, you can
70take advantage of the unique features of a particular solution, you don't
71have to limit yourself to some common denominator between multiple solutions.
72It is also less costly from a development standpoint, with only one interface
73layer to maintain and test. The wide approach is more operator-friendly: it
74lets deployers choose their preferred underlying implementation.
75
76Historically, OpenStack has opted for the wide approach, generally supporting
77as many underlying solutions as possible. Lately, a "narrow wide" approach
78was followed: while we still use indirection layers and support multiple
79options, we try to limit the number of options available. Only tested,
80featureful options are supported in mainline code, and only to the point
81where they provide useful choice. As a result of this, untested or
82non-functional or useless options are getting pruned, to focus on a
83limited set of options. That gives deployers some choice while keeping
84development cost/distraction under control.
85
86
87Proposed process for addition of new base services
88--------------------------------------------------
89
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).