moving specs directory from openstack-attic/akanda

Co-authored by: Sean Roberts <seanroberts66@gmail.com>
Co-authored by: Adam Gandelman <adamg@ubuntu.com>

Change-Id: I7fcf0af9753efd747a8bc96f00a90f2487d1a948

specs/README.rst

@@ -0,0 +1,35 @@
+OpenStack Akanda Specifications
+===============================
+
+This directory structure is used to hold approved design specifications for additions
+to the Akanda project.  Reviews of the specs are done in gerrit, using a
+similar workflow to how we review and merge changes to the code itself.
+
+The layout of this repository is::
+
+  specs/<release>/
+
+You can find an example spec in `specs/template.rst`. A
+skeleton that contains all the sections required for a spec
+file is located in `specs/skeleton.rst` and can
+be copied, then filled in with the details of a new blueprint for
+convenience.
+
+Specifications are proposed for a given release by adding them to the
+`specs/<release>` directory and posting it for review.  The implementation
+status of a blueprint for a given release can be found by looking at the
+blueprint in launchpad.  Not all approved blueprints will get fully implemented.
+
+Specifications have to be re-proposed for every release.  The review may be
+quick, but even if something was previously approved, it should be re-reviewed
+to make sure it still makes sense as written.
+
+Please note, Launchpad blueprints are still used for tracking the
+current status of blueprints. For more information, see::
+
+  https://wiki.openstack.org/wiki/Blueprints
+  http://blueprints.launchpad.net/akanda
+
+For more information about working with gerrit, see::
+
+  http://docs.openstack.org/infra/manual/developers.html#development-workflow

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

specs/kilo/skeleton.rst

@@ -0,0 +1 @@
+../skeleton.rst