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:
<hostname op="=" value="intel-grangeville-01.ml3.eng.bos.redhat.com"/>
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):
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
No <system_type/> tag in the result XML.
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:
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:
(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.
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:
However if you pass --machine xyz --systype Prototype, then you will get the desired behaviour as before:
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)
This bug fix is included in beaker-client-24.3-0.git.9.66a63d2 which is currently available for download here:
Beaker 24.3 has been released.