akanda/specs/kilo/ci-updates.rst

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