Bug 1055815

This sounds like a relatively straightforward fix, but it turns out to be impacted for existing instances by a couple of bugs/misfeatures in the way RHTS and the Task Library work.

Firstly, since per-recipe task library snapshotting was added in Beaker 0.13, if the RPM file for a task changes names, then recipes that had their task libraries created before the name change may break - Beaker will tell the harness to try to install the task using the *new* name, but the recipes's repo only has the task under the *old* name.

Secondly, as described in bug 1044934, the task library snapshotting means that downgrades are no longer supported properly, since the repo metadata may claim both the old and the new version exist (until another task is uploaded), but only the new version exists on disk. This is considered a necessary optimisation in the upload process (as fixing it would mean doubling the number of create repo calls), but means that there is a window where installation of the downgraded task may fail as yum tries to retrieve the old version (which no longer exists on disk) because it had a higher version number.

To address these problems in the near term, we'll need a couple of additional fixes:

- the reservesys version number will be bumped directly to 3.4 (because reasons)

- we'll add the capability to RHTS to force the use of a specific file name when generating RPMs for upload, rather than always deriving it from the source repo layout

Longer term, avoiding these kinds of version management problems is one of the key benefits of the git-based external tasks proposal (http://beaker-project.org/dev/proposals/external-tasks.html)

For the task library itself, we will likely switch to relying on the consistent "test(<name>)" virtual provides rather than the RPM names to handle installation. This won't solve the downgrade problem, but it will resolve the issue with the current dependency on consistent RPM names.

Adjusting the reservesys version number: http://gerrit.beaker-project.org/#/c/2715/

And forcing a particular RPM name in RHTS: http://gerrit.beaker-project.org/2717

If the task library snapshotting is working as intended, the following behaviours should be seen:

If a recipe is scheduled after the new task version is uploaded:

- recipe downloads and runs the *new* version of task

If a recipe is scheduled before the new task is uploaded, but runs afterwards:

- recipe downloads and runs the *old* version of the task

We know that name changes and downgrades can cause problems with the latter, but that's why the new version is deliberately designed to use the same RPM name and a higher version number.

Amit pointed out that with the current misbehaviour we're seeing, a reservesys task would *also* be able to see an updated version while it was running, even though the task library snapshotting is supposed to prevent that.

OK, I think I solved the mystery with seeming to be affected by bug 1044934, even though we specifically increased the version number to avoid that: the downgrade bug affects the required *test* procedure. We need 3 different versions, not just two.

In order to run the test case multiple times on a single instance, it needs to look something like:

1. Upload version X
2. Upload version Y
3. Submit a job and wait for the recipe to be scheduled
4. Upload version Z
5. Confirm the recipe succeeds and installs version Y

Where X < Y < Z

If you don't upload version X first, then the recipe will be afflicted by the downgrade bug, regardless of whether or not you upload version Z for a second time.

For reference, the issue with renaming task RPMs is covered by bug 1040258.

This change has now been published as http://beaker-project.org/tasks/beaker-distribution-reservesys-3.4-2.noarch.rpm