Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1055815 - Ensure /distribution/reservesys always sets a 0 return code
Summary: Ensure /distribution/reservesys always sets a 0 return code
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Community
Component: tests
Version: 0.15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: 0.15.3
Assignee: Nick Coghlan
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-21 01:21 UTC by Nick Coghlan
Modified: 2018-02-06 00:41 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-03 05:02:30 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1040258 None NEW task aborts if RPM name has changed in between scheduling the recipe and harness installing the task 2019-04-08 14:47:11 UTC
Red Hat Bugzilla 1044934 None CLOSED Correctly rebuild task library after downgrading a task 2019-04-08 14:47:11 UTC
Red Hat Bugzilla 1055821 None NEW Harness should rely on the stable test(<name>) virtual provides rather than exact RPM names. 2019-04-08 14:47:11 UTC

Internal Links: 1040258 1044934 1055821

Description Nick Coghlan 2014-01-21 01:21:49 UTC
/distribution/reservesys may set a non-zero return code when run in a test harness that doesn't provide the rhts_compat backwards compatibility machinery.

http://gerrit.beaker-project.org/#/c/2545/ fixes that.

Comment 1 Nick Coghlan 2014-01-21 01:52:26 UTC
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.

Comment 2 Nick Coghlan 2014-01-21 06:31:35 UTC
Adjusting the reservesys version number: http://gerrit.beaker-project.org/#/c/2715/

Comment 3 Nick Coghlan 2014-01-21 07:24:19 UTC
And forcing a particular RPM name in RHTS: http://gerrit.beaker-project.org/2717

Comment 6 Nick Coghlan 2014-01-23 01:00:23 UTC
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.

Comment 7 Nick Coghlan 2014-01-23 04:27:04 UTC
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.

Comment 8 Nick Coghlan 2014-01-23 07:07:11 UTC
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.

Comment 10 Nick Coghlan 2014-01-24 06:07:26 UTC
For reference, the issue with renaming task RPMs is covered by bug 1040258.

Comment 11 Nick Coghlan 2014-02-03 05:02:30 UTC
This change has now been published as http://beaker-project.org/tasks/beaker-distribution-reservesys-3.4-2.noarch.rpm


Note You need to log in before you can comment on or make changes to this bug.