openstack
/
arch-wg
Code Issues Proposed changes

Introduce expand/contract model for base services 

Recommend usage of an expand/contract model for base services.
I submitted it as an addendum to the base-service proposal.

Alternatively we could consider the base-service initial proposal
as implemented, and I could make this model its own proposal.

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

32
active/base-services.rst
View File

@ -93,6 +93,38 @@ 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.
Expand/contract model
---------------------
For the future we'd like to recommend the following approach for base services.
When a base service is added, there may be multiple solutions with different
benefits. One may be more stable but require specific operational expertise.
The other may be easier to operate but lacking features we might want to use
at some point in the future. It is difficult for developers to pick the best
trade-off if there is no natural winner: it's better to enable all the viable
options and ultimately leave that choice to the market of OpenStack users.
So 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.
Note that if initially one option only has benefits over the others, we should
**skip** the expand phase and directly only support that one option. Like 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 waste a few years experimenting with other
options just because we can. The expand phase is only needed if we can't pick
a natural winner in the first place.
Proposal
========