Plan for first iteration of CI gate infrastructure

This outlines some preliminary thoughts on upstream CI testing
for Akanda projects.

Implements blueprint ci-updates

Change-Id: I64b4d0b9f34e6e00b7ba6abcfdc1dd9408c3d13b

specs/kilo/ci-updates.rst

@@ -0,0 +1,191 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+
+Title of your blueprint
+=======================
+
+Akanda CI updates for Kilo
+
+Problem Description
+===================
+
+We build lots of interconnected things but dont test any of the things.  We
+should be employing pre-commit testing similar to other projects to ensure
+users get something thats not broken when deploying from master of git
+repositories or generated tarballs and images.
+
+Proposed Change
+===============
+
+All changes to Akanda projects should go through regular check and gate
+phases that test a deployment containing proposed code changes. This
+includes changes to Akanda code as well as supporting things like its devstack
+code and ``akanda-appliance-builder``.  We can leverage devstack, tempest
+and diskimage-builder to do this and create a generic Akanda integration
+testing job that can be added to the pipelines of relevant projects. We should
+also be running standard unit test coverage and pep8 checks here, too.
+
+For code that runs in the Akanda appliance VM or code that is used to build
+said image, we should ensure that tests run against proposed changes and not
+static, pre-built appliance images.  That is, runs that are testing changes
+to ``akanda-appliance`` should build and entirely new appliance VM image and
+use that for its integration tests instead of pulling a pre-built image that
+does not contain the code under review.
+
+Additionally, we should be archiving the results of changes to these
+appliance-related repositories as a 'latest' image. That is, if someone
+lands a change to ``akanda-appliance``, we should build and archive a
+VM image in a known location on the internet.  This will speed up other
+tests that do not need to build a new image but should run against the
+latest version, and also avoid forcing users to needlessly build images.
+
+For changes that do not modify the appliance code or tooling used to build
+the image, tests should run with a pre-built image. This can be either a
+'latest' image or a released, versioned image.
+
+One question at this point is where we run the Tempest jobs.  These usually
+take between 30min-1hr to complete and the nodes that run them in the main
+OpenStack gate are a limited resource. We may need to maintain our own third
+party CI infrastructure to do this. TBD.
+
+Data Model Impact
+-----------------
+
+None
+
+REST API Impact
+---------------
+
+None
+
+Security Impact
+---------------
+
+None
+
+Notifications Impact
+--------------------
+
+None
+
+Other End User Impact
+---------------------
+
+None
+
+Performance Impact
+------------------
+
+None
+
+Other Deployer Impact
+---------------------
+
+None
+
+Developer Impact
+----------------
+
+Developers hoping to land code in any of the Akanda repositories will need to
+ensure their code passes all gate tests before it can land.
+
+Community Impact
+----------------
+
+This may make landing changes a bit slower but should improve the overall
+quality and health of Akanda repositories.
+
+
+Alternatives
+------------
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+
+Work Items
+----------
+
+* Enable pep8 and unit test jobs against relevant Akanda repositories.
+
+* Move existing devstack code to out of ``http://github.com/dreamhost/akanda-devstack.git``
+  and into a proper gerrit-managed Akanda repository in the stackforge namespace.
+
+* Complete diskimage-builder support that currently exists in
+  ``http://github.com/stackforge/akanda-appliance-builder.git``
+
+* Update devstack code to either pull a pre-built Akanda appliance image from a
+  known URL or to build one from source for use in test run.
+
+* Create a generic ``(check|gate)-dsvm-tempest-akanda`` job that spins up the
+  Akanda devstack deployment and runs a subset of Tempest tests against it.
+
+* Identifiy the subset of Tempest tests we care to run.
+
+* Sync with openstack-infra and determine how and where these integration test
+  jobs will run.
+
+* Run the devstack job against changes to ``akanda-appliance`` or
+  ``akanda-appliace-builder`` with a configuration such that the appliance
+  image will be built from source including the patch under review.
+
+* Setup infrastructure to publish a new appliance image
+  (ie, akanda-appliance-latest.qcow2) to a known location on the internet
+  after code lands in ``akanda-appliance`` or ``akanda-appliance-builder``
+
+* Run the devstack job against all other relevant akanda repositories with a
+  configuration such that a pre-built appliance image from a known location on
+  the internet.  Ideally, this will be the image produced from changes to
+  the appliance repositories (ie, akanda-appliance-latest.qcow2)
+
+Dependencies
+============
+
+None
+
+Testing
+=======
+
+Tempest Tests
+-------------
+
+n/a
+
+Functional Tests
+----------------
+
+n/a
+
+
+API Tests
+---------
+
+n/a
+
+Documentation Impact
+====================
+
+User Documentation
+------------------
+
+Should be updated to reflect the new home of devstack code and proper ways to
+deploy it.
+
+Developer Documentation
+-----------------------
+
+Should be updated to reflect the new home of devstack code and proper ways to
+deploy it.
+
+References
+==========
+
+None