From 85eb0045f731580b91d52262d4f84a3aa72e2b6a Mon Sep 17 00:00:00 2001
From: Sean Dague <sean@dague.net>
Date: Fri, 27 Jun 2014 14:57:45 -0400
Subject: [PATCH] branchless tempest extensions spec

Lays out how the adding of branch specific service extensions can
be handled via our upstream gating system.

Change-Id: I974f8ac23f77169da0b921356c60fe80aef1bdd3
bp:branchless-tempest-extensions
---
 specs/branchless-tempest-extensions.rst | 102 ++++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 specs/branchless-tempest-extensions.rst

diff --git a/specs/branchless-tempest-extensions.rst b/specs/branchless-tempest-extensions.rst
new file mode 100644
index 0000000..3a7c1e5
--- /dev/null
+++ b/specs/branchless-tempest-extensions.rst
@@ -0,0 +1,102 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+=========================================
+ Branchless Tempest - Service Extensions
+=========================================
+
+https://blueprints.launchpad.net/tempest/+spec/branchless-tempest-extensions
+
+This is the follow on work for branchless tempest for new service
+extensions that are added over the course of a release.
+
+Problem description
+===================
+In moving to branchless Tempest we're now running Tempest across
+multiple OpenStack code branches. Today that's icehouse and juno,
+however it will be icehouse, juno, kepler in the future.
+
+What happens when a new extension is added to Nova in Juno, and tests
+in tempest are wanted for that part of the API? Today that test would
+fail because it could not pass icehouse.
+
+Proposed change
+===============
+The proposed change is to add another layer to the devstack-gate
+feature grid which specifies which extensions are supported at each
+release.
+
+Today in the nova definition we've got ::
+
+    nova:
+      base:
+         services: [n-api, n-cond, n-cpu, n-crt, n-net, n-obj, n-sch]
+
+This would imagine a world where the definition would look as follows
+::
+
+    nova:
+      base:
+         services: [n-api, n-cond, n-cpu, n-crt, n-net, n-obj, n-sch]
+      icehouse:
+         compute-ext: [floating-ips, aggregates, ... ]
+
+The non existance of an extensions list means assume 'all'. It is also
+expected that you'd be able to specify 'rm-compute-ext' much like
+rm-services, so that you could do something as follows.
+::
+
+      nova-cells:
+        base:
+          services: [n-cell]
+          rm-compute-ext: [aggregates, hosts]
+
+That would disable those nova extensions any time it was configured.
+
+For this to function there needs to be changes in
+
+- devstack-gate
+
+  - to parse these additional stanzas and pass them down to devstack
+
+- devstack
+
+  - to take extension lists for projects and set the correct
+    extensions up based on it
+  - to compute the 'all' case correctly for master (especially if we
+    support the rm-compute-ext stanza)
+  - to set the correct tempest fields for enabled features when these
+    map to feature flags.
+
+
+Alternatives
+------------
+Nova API microversions might obviate the need here in the branch case,
+as we'd be able to specify a specific test has a specific required
+version. However that wouldn't solve the cells case.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+Primary assignee:
+  None yet
+
+
+Milestones
+----------
+Not Known
+
+
+Work Items
+----------
+The work items span projects
+
+- see above
+
+Dependencies
+============
+Only those listed above