Bug 1234323 - options --machine and --systype not compatible
Summary: options --machine and --systype not compatible
Alias: None
Product: Beaker
Classification: Community
Component: command line
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified vote
Target Milestone: 24.3
Assignee: Dan Callaghan
QA Contact: Dan Callaghan
Keywords: Patch
Depends On:
TreeView+ depends on / blocked
Reported: 2015-06-22 11:34 UTC by Michael Petlan
Modified: 2017-05-30 07:08 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2017-05-30 07:08:03 UTC

Attachments (Terms of Use)

Description Michael Petlan 2015-06-22 11:34:10 UTC
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">
                                        <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):

How reproducible:

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

Actual results:

No <system_type/> tag in the result XML.

Expected results:

Having <system_type op="=" value="Prototype"/> in the XML.

Comment 1 Dan Callaghan 2015-06-24 06:58:29 UTC
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.

Comment 2 Dan Callaghan 2016-10-26 06:38:49 UTC
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:



Comment 3 Dan Callaghan 2016-10-26 06:43:16 UTC
(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.

Comment 4 Dan Callaghan 2017-05-17 02:49:16 UTC
Ahh sorry, I lost track of this bug. We should definitely just undo bug 1095026.

Comment 5 Dan Callaghan 2017-05-22 06:42:45 UTC

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:

    <hostname value="xyz"/>
    <system_type value="Prototype"/>

Comment 6 Michael Petlan 2017-05-22 12:06:26 UTC
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.

Comment 7 Dan Callaghan 2017-05-22 21:36:54 UTC
(In reply to Michael Petlan from comment #6)


Comment 8 Dan Callaghan 2017-05-29 02:25:49 UTC
This bug fix is included in beaker-client-24.3-0.git.9.66a63d2 which is currently available for download here:


Comment 10 Dan Callaghan 2017-05-30 07:08:03 UTC
Beaker 24.3 has been released.

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