Description of problem: When a machine is specified by --machine option, it can be only from Machine subset. If the machine is a Prototype, then it cannot be used by the following commandline: bkr workflow-whateverworkflow --machine=my-desired.machine.lab.redhat.com --task .... since the scheduler adds <system_type op="=" value="Machine"/> into the recipe. If I want to override it by using the "--systype=Prototype" option, it works only when "--machine" is not used. So the following: bkr workflow-whateverworkflow --machine=my-desired.machine.lab.redhat.com --systype=Prototype --reserve returns this XML: <job retention_tag="Scratch"> [....] <hostRequires> <and> <hostname op="=" value="intel-grangeville-01.ml3.eng.bos.redhat.com"/> </and> </hostRequires> [....] </job> So since there is no <system_type/> tag there (it should be because of the command line specification), the scheduler adds <system_type op="=" value="Machine"/> there and the job aborts with "no matching systems". Version-Release number of selected component (if applicable): beaker-client-20.1-1.el7sed.noarch How reproducible: 100% Steps to Reproduce: 1. tomorrow --machine=intel-grangeville-01.ml3.eng.bos.redhat.com --systype=Prototype --arch x86_64 --distro RHEL-6.7-20150617.0 --reserve --dryrun 2. 3. Actual results: No <system_type/> tag in the result XML. Expected results: Having <system_type op="=" value="Prototype"/> in the XML.
Hmmm interesting situation. That was an intentional change we made a while ago in 0.17.0, to ignore any other system selection options when --machine is given: https://git.beaker-project.org/cgit/beaker/commit/?id=5c7de242e2f2882dcafa17b1bdf3ae6af179d794 https://bugzilla.redhat.com/show_bug.cgi?id=1095026 but it didn't occur to us that adding --systype might be necessary even with --machine. As a workaround, you should be able to replace --machine=example.com with --hostrequire=hostname=example.com when invoking the workflow.
So I guess we have two options here... Change --machine so that it produces <hostRequires force=""/> instead. This fits a bit closer with its current behaviour (when force="" is used, no other host filters are accepted) and it will let you pick Prototypes (as well as Broken systems and so forth). Or just revert this entirely: https://git.beaker-project.org/cgit/beaker/commit/?id=5c7de242e2f2882dcafa17b1bdf3ae6af179d794 https://bugzilla.redhat.com/show_bug.cgi?id=1095026
(In reply to Dan Callaghan from comment #2) > Change --machine so that it produces <hostRequires force=""/> instead. Actually this might not make sense, since we already have --ignore-system-status which changes --machine from producing <hostname value=""/> to use force="" instead. See bug 1319988 and related history. So it seems like just reverting bug 1095026 is the right answer here.
Ahh sorry, I lost track of this bug. We should definitely just undo bug 1095026.
https://gerrit.beaker-project.org/5697 So with this patch, if you pass --machine xyz --ignore-system-status --systype Prototype, you will still get a warning and --systype will still be ignored as before. We have to do that, otherwise would be producing invalid job XML (and you don't need <system_type/> in this case anyway). It will produce: <hostRequires force="xyz"/> However if you pass --machine xyz --systype Prototype, then you will get the desired behaviour as before: <hostRequires> <hostname value="xyz"/> <system_type value="Prototype"/> </hostRequires>
So do I understand correctly that after the patch, using '--machine xyz --systype Prototype' will behave as expected and reserve the Prototype machine 'xyz'? Thanks.
(In reply to Michael Petlan from comment #6) Yes.
This bug fix is included in beaker-client-24.3-0.git.9.66a63d2 which is currently available for download here: https://beaker-project.org/nightlies/release-24/
Beaker 24.3 has been released.