openstack/governance
Code Issues Proposed changes

Include a rationale for tracking base services

Browse Source 
It was pointed out in #openstack-tc[*] that we may be making some
assumptions about the reasons for base services without having fully
expressed them in any durable form. As an example, when we added a
distributed lock manager to this list the driving reason was that
several services had already implemented their own (some completely
independently, some by copying from other services and then perhaps
making modifications). There are times when we solve this problem by
adding new shared libraries, hence the remit of Oslo, but some
solutions need full-blown services in their own right which may or
may not be developed within the OpenStack community.

We also realize that deployments may be hesitant to turn on useful
features by default because they rely on yet another service, and
this hampers adoption of something which if ubiquitous would perhaps
snowball into the addition of similar useful default capabilities
in OpenStack deployments.

[*] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-16.log.html#t2018-05-16T17:55:51

Change-Id: Ie85658e95dad210ea8ef838eb2fb5a571ed02cab
This commit is contained in:
Jeremy Stanley
2018-05-16 19:19:43 +00:00
parent 42ec05c360
commit d3bf319012
1 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
reference/base-services.rst
View File

@@ -11,6 +11,29 @@ leverage advanced features exposed by those base services without fear of
increasing the overall operational complexity for OpenStack deployers.
Rationale
=========
There are two related reasons behind the existence of this list. First and
most straightforward, as stated by the Definition above, OpenStack
components are allowed to rely on a solution listed here without needing to
provide an alternative or fallback mechanism to account for situations when
the solution is not present. The other and perhaps more subtle reason is to
drive consistency of implementation between different OpenStack components
who may have similar needs but would otherwise likely end up embedding
their own varied implementations.
When someone developing a new feature is aware that there is a standard
solution provided by this list, they are likely (and encouraged) to use it
instead of designing something from scratch. This helps mitigate the risk
that multiple components might otherwise independently provide similar but
divergent solutions to the same basic problem space. It's also intended to
encourage more useful base functionality by default across OpenStack
components, because the perceived cost (to performance or complexity) of
including this one extra dependency is lessened by each other component of
the system which may also benefit from using it.
Current list of base services
=============================