From f6118a045d419653f5499e7562ba1cc995bd6100 Mon Sep 17 00:00:00 2001 From: Thierry Carrez Date: Thu, 23 Mar 2017 12:13:52 +0100 Subject: [PATCH] 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 --- active/base-services.rst | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/active/base-services.rst b/active/base-services.rst index 97d4f20..7dc7332 100644 --- a/active/base-services.rst +++ b/active/base-services.rst @@ -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 ========