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.
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.
The RFE to force a relocated task to keep its old name is bug 1044913
(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.
(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.
(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
(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.
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.
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