Home Wiki > openSUSE:OpenStack and Crowbar development process
Sign up | Login

openSUSE:OpenStack and Crowbar development process

tagline: From openSUSE

Development, testing, and continuous integration (CI) of OpenStack and Crowbar on openSUSE

We use Jenkins to automatically package changes from upstream git repositories into rpms within an openSUSE environment, and if they successfully build and install, Jenkins commits those changes to the Open Build Service (OBS) which then automatically builds and publishes canonical packages and images.

Detailed workflow

Suse cloud 2.0.png

Let's start chronologically through the live from a code change to a final package to a final product.


Let's look first at changes to a released OpenStack version (the graph and the text uses the Grizzly release for this):

OpenStack is developed on github.com and once a check-in to Folsom branches occurs, the daily Jenkins trackupstream job checks out the changes, creates a new tar ball, builds and installs the package and if that is successful, submits it to an OBS staging project.

Once all packages and its dependencies are built, Jenkins runs test jobs (e.g. functional tests: cloud-cleanvm and the upstream OpenStack unit tests for each component). If the new package passes these tests, the package is automatically pushed from the OBS staging project (e.g. Cloud:OpenStack:Grizzly:Staging once Grizzly is released) to the main one (e.g. Cloud:OpenStack:Grizzly).

The openSUSE distributions always ships the latest stable OpenStack release (Folsom at the time of writing). The package submission workflow for openSUSE is decoupled from regular OpenStack packaging work. To facilitate the openSUSE:Factory development model, packages are prepared in the Cloud:OpenStack:Factory project and submitted regularly to openSUSE:Factory for review and inclusion in the openSUSE development branch (Factory).


Currently Chef 10 and 11 are both built directly from upstream, in systemsmanagement:chef:10 and systemsmanagement:chef:master respectively. This is likely to change soon, now that Chef 11 is released. systemsmanagement:chef:10:staging is a branch of systemsmanagement:chef:10 which allows testing of packaging changes without destabilising the overall build. However, since we are not tracking upstream changes on a regular basis, there is no Jenkins job involved here.


Changes are sent to the https://github.com/crowbar upstream repositories via github pull requests. This is gated by manual peer code review, and in the future hopefully also by Travis runs.

systemsmanagement:crowbar:2.0:staging is closely tracking github upstream, and this process is automated via a Jenkins job. Also, Travis CI runs unit tests on the same upstream.

systemsmanagement:crowbar:2.0:staging is a branch of systemsmanagement:crowbar:2.0, and currently changes are pushed from staging via manual submitreq; however in the future we aim to have automatic integration tests as part of this gate.

In these Crowbar projects, there is also the special package Crowbar_2.0 which contains a kiwi configuration (kiwi is the tool we use to create all our distribution/product images with). The build service is able to use that to build working ISO images. You can also build an image locally by just checking out the Crowbar_2.0 package using the osc tool and running osc build images inside the checked out directory.

Tying it all together

To make deployment of a cloud easy - and to run integration tests of the complete stack, all the needed cloud packages, OpenStack, Crowbar, Chef and other components - are to be aggregated (a copy of the binaries) into the project isv:SUSE:Cloud:2.0:Staging. Once these packages get updated, an integration test of all components is done by Jenkins. The tests include mkcloud and tempest. If this testing passes, the packages end in isv:SUSE:Cloud:2.0.

The naming here is isv:SUSE:Cloud:2.0 since this is similar to the setup for SUSE's SUSE Cloud product based on SUSE Linux Enterprise. The openSUSE packages in isv:SUSE:Cloud:2.0 can be used as is.