openstack
/
arch-wg
Code Issues Proposed changes

Proposed model for alternatives in base services 

For base services, the recommended pattern should be to only
support one solution, if one solution is clearly superior to
the others. If there are multiple viable alternatives, we should
adopt an expand/contract model.

Change-Id: I9fa277d84b2232f23eeacb5316386851c4a8b0e2
This commit is contained in:
Thierry Carrez 2017-03-23 12:13:52 +01:00
parent fbdca57171
commit f6118a045d
1 changed files with 33 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
active/base-services.rst
View File

@ -93,6 +93,39 @@ non-functional or useless options are getting pruned, to focus on a
limited set of options. That gives deployers some choice while keeping
development cost/distraction under control.
Pick one if possible, expand/contract if no clear winner
--------------------------------------------------------
For the future we'd like to recommend the following approach for base services.
When a base service is added, there may be multiple implementation solutions.
If one option only has benefits over the others, we should directly only
support that one option. For example, if one option has all the features we
need, and does not present any specific operational or licensing challenge
that would make it unfit in certain environments, there is no need to
introduce an indirection and supporting inferior options just because we can.
However, if we can't easily pick a natural winner, we should adopt a expand
and contract model. One option may be more stable but require specific
operational expertise. Another may be easier to operate but lacking features
we might want to use at some point in the future. In those cases it is
difficult for developers to pick the best trade-off: it's better to enable
all the viable options and ultimately leave that choice to the market of
OpenStack users.
In that situation, when the base service is added, we initially start with
an **expand** phase: support all the viable alternatives through an
indirection layer, deliver the base functionality for OpenStack project
to start making use of them, and see for real which option meets the
requirements of OpenStack deployers the best.
If, in the future, the users market converges to using one option (like 90%
of deployments end up using one specific backend), we need to switch to the
**contract** phase. Deprecate support for the alternate options, and provide
users with help to migrate to the dominant option. Then at the end of the
deprecation period, only support one option, and start taking advantage of
the unique feature set of that option.
Proposal
========