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. """
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
(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.
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 ...
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.
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).