Using a Branch Under Review in TripleO

One of the unintended consequences of Feature Freeze in OpenStack is that a lot of new features get merged in a hurry at the end of the cycle. That's obviously not ideal, but it's a reality we all have to live with for now. TripleO has been bitten by this a few times recently, and the long gate queue that also goes along with Feature Freeze means sometimes fixes for problems take a long time (days) to merge in the other projects. In the gate we have tempreverts and cherry-picks to mitigate that problem, but for local devtest those features are not available. Fortunately there's another solution.

First, I should note that we don't like doing this. We want to be running as close to the "upstream" projects' master branches as possible, so the technique I'm about to describe should only be used in exceptional circumstances. With the disclaimers out of the way, let's get to the interesting bits.

The short version is that diskimage-builder provides two environment variables to control which git repos it uses to build our TripleO images: DIB_REPOLOCATION and DIB_REPOREF. Here's an example of how to set those to fix a problem that is currently breaking TripleO deploys:

export DIB_REPOLOCATION_neutron=https://review.openstack.org/openstack/neutron
export DIB_REPOREF_neutron=refs/changes/34/121434/2

These values can be found on the Gerrit review page in the Download section of the patch set details. You will see a line that looks something like this (color added for easier reference):

git fetch https://review.openstack.org/openstack/neutron refs/changes/34/121434/2 && git checkout FETCH_HEAD

The red part is what goes in DIB_REPOLOCATION and the blue part is what goes in DIB_REPOREF. Also note the project name suffix that must be appended to the end of both variables to specify which project they are referring to.

Another option if you simply need to revert a git repo back to a specific point in time is to only set the DIB_REPOREF. In this case it needs to be a valid commit hash from the master branch of the project. I haven't actually tried running devtest this way so I can't promise it will work as I describe, but as I understand it this should be an option too.