Bug 1575900 - Fedora-27 machine reservation does not work - waits until timeout
Summary: Fedora-27 machine reservation does not work - waits until timeout
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Beaker
Classification: Community
Component: general
Version: develop
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 08:36 UTC by Denys Vlasenko
Modified: 2018-10-16 00:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 00:33:26 UTC


Attachments (Terms of Use)

Description Denys Vlasenko 2018-05-08 08:36:28 UTC
Example:

https://beaker.engineering.redhat.com/recipes/5120706
"""
Queued 18 hours ago.
Using Fedora-27-20171110.n.1 Workstation x86_64
on 488 possible systems.

Installation of Fedora-27-20171110.n.1 Workstation x86_64 not started.
"""

Comment 1 Roman Joost 2018-05-09 01:57:03 UTC
Dear Denys,

thank you for this bug report. I looked into what happened and I would like to ask to provide more information.

The chosen distro  Fedora-27-20171110.n.1 Workstation x86_64 is only located at the BLR lab controller (https://beaker.engineering.redhat.com/distrotrees/85243#lab-controllers), yet the 488 possible systems Beaker claims could be used are not in BLR. I think that recipe will never run.

How did you end up with this job? Did you use the reserve workflow, pick the Fedora27 family and the first distro which was selectable? That's how I would end up with a job like this at least ...

Short term for you: 

* cancel the job
* go back to the reserve workflow, pick the Fedora27 family
* pick tag: RELEASED
* pick a suitable distro and try again

Comment 2 Denys Vlasenko 2018-05-14 07:56:14 UTC
(In reply to Roman Joost from comment #1)
> How did you end up with this job? Did you use the reserve workflow, pick the
> Fedora27 family and the first distro which was selectable?

Exactly.

Comment 3 Roman Joost 2018-05-15 05:18:31 UTC
Thanks for the reply. I guess the other odd thing for this bug is that Beaker claims the 488 possible systems for the given distro, yet these are not valid since they're not in BLR. I'll have to do more digging what's causing this ...

Comment 4 Dan Callaghan 2018-05-15 05:46:58 UTC
That is the "expected" behaviour, it is assuming that because the distro has appeared in BLR, Globalsync will "soon" copy it to all the other labs and then those 488 possible systems will be able to run the recipe.

Whereas it seems this tree only ever appeared in BLR and nowhere else (and its naming scheme does not match what we normally expect for Fedora) so the real question would be, why did this tree appear at all, and why only in BLR? I'm guessing an admin imported it by hand for some reason.

Comment 6 Dan Callaghan 2018-10-16 00:33:26 UTC
The weaknesses/limitations around how distros are imported and expired (and this specific issue of a distro appearing in one lab and not the others erroneously) was planned to be addressed as part of the "next-generation distro library" roadmap item.

There is also bug 629155 about the issue of Beaker picking a newer distro with limited availability when it could have picked an older one with better availability (which is true, although it is the expected/desired behaviour today).


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