From 3bcb84b51257eec508c8f0830d867ddc3e8735b6 Mon Sep 17 00:00:00 2001 From: Adam Gandelman Date: Mon, 27 Apr 2015 17:10:59 -0700 Subject: [PATCH] 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 | 191 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 specs/kilo/ci-updates.rst diff --git a/specs/kilo/ci-updates.rst b/specs/kilo/ci-updates.rst new file mode 100644 index 0000000..ee6c8d1 --- /dev/null +++ b/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