As explained in a previous post, in RDO Trunk repositories we try to provide packages for new commits in OpenStack projects as soon as possible after they are merged upstream. This has a number of advantages:
- It allows packagers to identify packaging issues just after introduced.
- For project developers, their changes are tested in non-devstack environments, so test coverage is extended.
- For deployment tools projects, they can use these repos to identify problems with new versions of packages and to start integrating any enhancement added to projects as soon as it’s merged.
- For operators, they can use these packages as hot-fixes to install in their RDO clouds before patches are included in official packages.
This means that, for every merged commit a new package is created and a yum repository is published in RDO trunk server. This repo includes the just built package and the latest builds for the rest of packages in the same release.
Initially, we applied this approach to every package included in RDO. However, while testing these repos during the Newton cycle we observed that jobs failed with errors that didn’t affect OpenStack upstream gates. The reason behind this is that commits in OpenStack gate jobs are tested with versions of libraries and clients defined in upper-constraints.txt files in requirements project for the branch where the change is proposed. Typically these are the last tag-released versions. As RDO was testing using libraries from last commit instead of last release, we were effectively ahead of upstream tests, running too fast.
While this provided some interesting information and we could identify issues very early, it made very difficult to get stable repositories that could be promoted and used. After some discussions in RDO weekly meeting, it was decided to apply some changes in the way libraries are managed to leverage the work done in upstream gates but try to keep catching issues as soon as possible:
- For master branch, it was decided to pin libraries and clients to the versions included in upper-constraints for repositories served in http://trunk.rdoproject.org/centos7. This repositories are used by RDO CI promotion jobs and marked as current-passed-ci when all tests succeed.
- Additionally, a new builder was created that chases master in all packages, including libraries, clients, etc… This builder is able to catch issues based on unit tests executed when packages are created. The produced repos are available in http://trunk.rdoproject.org/centos7-master-head but promotion jobs are not executed using them.
The differences between master and master-head are shown in following diagram:
- For releases in maintenance phase we pin libraries to what’s found in upper-constraints.txt file in the corresponding branch.
In order to manage the libraries versions properly, RDO is using a peer-reviewed workflow of gerrit reviews proposed to the rdoinfo project in http://review.rdoproject.org. You can see an example here.
A job is executed periodically that automatically creates gerrit reviews when versions are updated in upper-constraints files. Manual approval is needed to get the changes merged and the new versions built by DLRN builders.