Description of problem: If a system is broken (for example), job submitted via `bkr machine-test` will be aborted. This can be a limiting feature for some of the same reasons described in https://bugzilla.redhat.com/show_bug.cgi?id=851354#c9 . Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Two possible solutions: 1. A new switch --force be added to force the system provisioning 2. Make this the default behaviour Additional info:
(In reply to Amit Saha from comment #0) > Two possible solutions: > > 1. A new switch --force be added to force the system provisioning This patch implements this solution: http://gerrit.beaker-project.org/#/c/3048/
(In reply to Amit Saha from comment #0) > Two possible solutions: > 1. A new switch --force be added to force the system provisioning > 2. Make this the default behaviour After discussing this with Nick, we think number 2 is the way to go. If you are naming a specific system then there is really no reason you would ever want the scheduler to abort your job. So we can use force="" unconditionally in bkr machine-test. It means we are effectively treating this as a bug, rather than an RFE (and the release note should be worded to reflect that): Previously if you ran machine-test against a system that was Broken, Beaker aborted your recipe saying "No matching systems". Now, Beaker will do what you asked. Flipping this back to ASSIGNED since the patch will need tweaking.
(In reply to Dan Callaghan from comment #3) > (In reply to Amit Saha from comment #0) > > Two possible solutions: > > 1. A new switch --force be added to force the system provisioning > > 2. Make this the default behaviour > > After discussing this with Nick, we think number 2 is the way to go. If you > are naming a specific system then there is really no reason you would ever > want the scheduler to abort your job. So we can use force="" unconditionally > in bkr machine-test. Not sure I am clear about the reasoning. When you submit a job using <hostRequires> (without force) for a system which is broken/manual, the job will be aborted. This is the "default" behavior. If we implement `bkr machine-test` as per 2, this means it will have a different "default" behavior. That seems inconsistent to me. Of course, if the reasoning is that `bkr machine-test` has a different use case and is thus expected to work differently, that is reasonable and hence this is a bug and 2 is the correct solution.
bkr machine-test (like other workflow commands) have a --machine and a --hostrequire switch. Now, if you specify both these, the job gets the following in <hostRequires> (for example): <hostRequires> <hostlabcontroller op="=" value="testlc.labcontroller"/> <hostname op="=" value="test.system"/> </hostRequires> So, if we *do not* want to have an extra force switch, here is what I can think of: 1. If only --machine is specified, we force provision irrespective of the status 2. If both --machine and --hostrequire are specified, we ignore --hostrequire completely 3. If only --hostrequire is specified, we do the usual (no forced provisioning)
(In reply to Amit Saha from comment #5) > 2. If both --machine and --hostrequire are specified, we ignore > --hostrequire completely This seems like an existing flaw in the option handling. If --machine is given it should be mutually exclusive with the other system selection options (--hostrequire, --type, ...) and it should trigger a usage error. It doesn't make sense to select a particular hostname and then also apply additional filtering.
(In reply to Dan Callaghan from comment #6) > (In reply to Amit Saha from comment #5) > > 2. If both --machine and --hostrequire are specified, we ignore > > --hostrequire completely > > This seems like an existing flaw in the option handling. If --machine is > given it should be mutually exclusive with the other system selection > options (--hostrequire, --type, ...) and it should trigger a usage error. It > doesn't make sense to select a particular hostname and then also apply > additional filtering. Yeah, seems like. Filed bug 1095026 (with patch).
Bug 1095026 resolves the issue of both "machine" and "hostrequire" (and others) being specified by always considering only "machine" into account. For the purpose of this RFE, "force" will now always be enforced as per comment 3.
(In reply to Amit Saha from comment #8) > > For the purpose of this RFE, "force" will now always be enforced as per > comment 3. As per further discussion at https://lists.fedorahosted.org/pipermail/beaker-devel/2014-May/001015.html, there will be a separate switch for bkr machine-test which is 'ignore-system-status'. The default behavior remains unchanged. http://gerrit.beaker-project.org/#/c/3048/
Beaker 0.17.0 has been released.