Bug 1040258 - task aborts if RPM name has changed in between scheduling the recipe and harness installing the task
Summary: task aborts if RPM name has changed in between scheduling the recipe and harn...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Beaker
Classification: Retired
Component: general
Version: 0.15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-11 03:29 UTC by Dan Callaghan
Modified: 2020-04-21 08:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-21 08:49:35 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1044913 0 high CLOSED [RFE] Allow the task prefix to be overridden 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1055815 0 unspecified CLOSED Ensure /distribution/reservesys always sets a 0 return code 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1055821 0 unspecified CLOSED Harness should rely on the stable test(<name>) virtual provides rather than exact RPM names. 2021-02-22 00:41:40 UTC

Internal Links: 1044913 1055815 1055821

Description Dan Callaghan 2013-12-11 03:29:30 UTC
Version-Release number of selected component (if applicable):
0.15.1

Steps to Reproduce:
1. Submit a recipe with several tasks
2. After the recipe has been scheduled, but before the second task is installed by beah, upload a new version of the task with a different RPM name

Actual results:
Task aborts because beah cannot install the RPM under its new name. The task repo contains the task under its old name, snapshotted when the recipe was scheduled.

Expected results:
Recipe works properly, harness installs the task from the task repo.

Additional info:
The only reason why task RPM names can change is because they are prefixed with a string generated from the VCS location. This prefix serves no actual purpose and should just be removed, except even removing the prefix will trigger this problem also.

One possible solution might be for beah to install the task using the test() virtual provides, which is not sensitive to the RPM name.

Comment 2 Nick Coghlan 2013-12-11 03:40:58 UTC
For now, we also need a workaround to force the use of a particular prefix in the task RPM names, so we can generates RPMs from the beaker-core-tasks repo under their old names.

Comment 3 Nick Coghlan 2013-12-20 00:38:29 UTC
The RFE to force a relocated task to keep its old name is bug 1044913

Comment 4 Amit Saha 2013-12-20 01:27:48 UTC
(In reply to Dan Callaghan from comment #0)
> Version-Release number of selected component (if applicable):
> 0.15.1
> 
> Steps to Reproduce:
> 1. Submit a recipe with several tasks
> 2. After the recipe has been scheduled, but before the second task is
> installed by beah, upload a new version of the task with a different RPM name

A key point that you note implicitly, but worth making it explicit is that this succeeds only when the version string has changed. We added the UNIQUE constraint on the task name not so long ago, and this prevents the same task with a different RPM name but the same version from being uploaded.

> 
> Actual results:
> Task aborts because beah cannot install the RPM under its new name. The task
> repo contains the task under its old name, snapshotted when the recipe was
> scheduled.

I think this behaviour will also be demonstrated when a different version of the same task has been uploaded after the recipe was scheduled. 

> 
> Expected results:
> Recipe works properly, harness installs the task from the task repo.
> 
> Additional info:
> The only reason why task RPM names can change is because they are prefixed
> with a string generated from the VCS location. This prefix serves no actual
> purpose and should just be removed, except even removing the prefix will
> trigger this problem also.
> 
> One possible solution might be for beah to install the task using the test()
> virtual provides, which is not sensitive to the RPM name.

Comment 5 Dan Callaghan 2013-12-20 02:54:00 UTC
(In reply to Amit Saha from comment #4)
> (In reply to Dan Callaghan from comment #0)
> > Actual results:
> > Task aborts because beah cannot install the RPM under its new name. The task
> > repo contains the task under its old name, snapshotted when the recipe was
> > scheduled.
> 
> I think this behaviour will also be demonstrated when a different version of
> the same task has been uploaded after the recipe was scheduled. 

It shouldn't, because one of the things schedule_queued_recipe() does is create a snapshot of the entire task repo using hardlinks, so any newly uploaded or unlinked tasks after that point cannot affect the existing snapshot.

Comment 6 Nick Coghlan 2013-12-20 02:59:19 UTC
(In reply to Amit Saha from comment #4)
> (In reply to Dan Callaghan from comment #0)
> > Actual results:
> > Task aborts because beah cannot install the RPM under its new name. The task
> > repo contains the task under its old name, snapshotted when the recipe was
> > scheduled.
> 
> I think this behaviour will also be demonstrated when a different version of
> the same task has been uploaded after the recipe was scheduled. 

As Dan noted, that won't happen in the general - it's the whole reason for pre-generating the task repos with a hard link to the original RPM.

The relevant code is in RecipeTask.to_xml [1] - that strips the version details from the RPM name, and only reports the unqualified name. That way the harness will grab whatever version is in the repo created for the recipe, rather than the version that was uploaded to the server.

However, there's a different problem with a poor user experience for downgrades, which is covered by bug 1044934.

[1] http://git.beaker-project.org/cgit/beaker/tree/Server/bkr/server/model.py?id=80f4711bc9977a3413b2062dca79642dbfaf3bc3#n6380

Comment 7 Amit Saha 2013-12-20 03:50:10 UTC
(In reply to Nick Coghlan from comment #6)
> (In reply to Amit Saha from comment #4)
> > (In reply to Dan Callaghan from comment #0)
> > > Actual results:
> > > Task aborts because beah cannot install the RPM under its new name. The task
> > > repo contains the task under its old name, snapshotted when the recipe was
> > > scheduled.
> > 
> > I think this behaviour will also be demonstrated when a different version of
> > the same task has been uploaded after the recipe was scheduled. 
> 
> As Dan noted, that won't happen in the general - it's the whole reason for
> pre-generating the task repos with a hard link to the original RPM.
> 
> The relevant code is in RecipeTask.to_xml [1] - that strips the version
> details from the RPM name, and only reports the unqualified name. That way
> the harness will grab whatever version is in the repo created for the
> recipe, rather than the version that was uploaded to the server.
> 
> However, there's a different problem with a poor user experience for
> downgrades, which is covered by bug 1044934.

Correct, yeah, sorry I was thinking something else. It will simply use the pre-existing task RPM, rather than the new task RPM.

Comment 8 Nick Coghlan 2014-01-24 06:04:48 UTC
Bug 1055821 is an RFE to switch to instructing tasks to install entries from the task library based on the test(<name>) virtual provides rather than the RPM name.

If it proves to work correctly in all supported versions of yum, then that RFE should also resolve this issue.

Comment 9 Martin Styk 2020-04-21 08:49:35 UTC
Closing this issue.
We are not planning to address this problem in the Beaker development lifecycle.

Instead of that, we are planning to continue our effort in building Beaker.NEXT.
If you have any questions, feel free to reach out to me.

Best regards,
Martin Styk


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