The current command for reserving an Automated system via the command line is: bkr simple-workflow --task /distribution/reservesys --arch x86_64 --family <distro>" To reserve a specific Manual or Broken system it is: bkr simple-workflow --task /distribution/reservesys --ignore-system-status --machine <FQDN> --family <distro>" That's not particularly discoverable, especially as the simple-workflow documentation doesn't mention this use case. This RFE proposes simplifying the Automated case to "bkr reserve-workflow --family <distro>" and the Manual/Broken case to "bkr reserve-workflow --machine <FQDN> --family <distro>" Relative to simple-workflow, I'm suggesting the following adjustments (but am open to discussion on all of them): * additional --task options would not be accepted * if "--arch" is missing and --machine is not given, then --arch defaults to "x86_64" rather than "all known arches" * if "--machine" is given, then "--ignore-system-status" is implied The man page for the new command can then tie it together with the common host filtering options through some examples. A dedicated command should make this capability more discoverable, without cluttering up the simple-workflow page with reserve-workflow specific guidance. A follow on change can then update the Reserve Workflow page with a link to the documentation.
Increased complexity estimate a bit, as there's a bit of design work involved, as well as the usage examples to put together.
> To reserve a specific Manual or Broken system it is: > > bkr simple-workflow --task /distribution/reservesys > --ignore-system-status --machine <FQDN> --family <distro>" > This does not work because of bug https://bugzilla.redhat.com/show_bug.cgi?id=1319988#c0
> Relative to simple-workflow, I'm suggesting the following adjustments (but > am open to discussion on all of them): > > * additional --task options would not be accepted > * if "--arch" is missing and --machine is not given, then --arch defaults to > "x86_64" rather than "all known arches" > * if "--machine" is given, then "--ignore-system-status" is implied > > The man page for the new command can then tie it together with the common > host filtering options through some examples. > > A dedicated command should make this capability more discoverable, without > cluttering up the simple-workflow page with reserve-workflow specific > guidance. > > A follow on change can then update the Reserve Workflow page with a link to > the documentation. I like the proposed ideas. @Dan, @Roman, what do you guys think?
Go ahead Matt. Do it!
(In reply to Nick Coghlan from comment #0) > Relative to simple-workflow, I'm suggesting the following adjustments (but > am open to discussion on all of them): > > * additional --task options would not be accepted > * if "--arch" is missing and --machine is not given, then --arch defaults to > "x86_64" rather than "all known arches" If "--arch" is missing and --machine is given, I think "--arch" should default to "x86_64" as well.
On Gerrit: https://gerrit.beaker-project.org/#/c/5581/
Matt is moving to another team and there is currently no one who immediately can continue on this patch. Moving this back to NEW.
What about using bkr worflow-tomorow? I think it already supports most of the desired features. If no task is specified --reserve is implied. I you need just one arch you can use --free or simply specify --arch x86_64 e.g. For example to reserve all supported architectures with latest released rhel7 you simply run: bkr workflow-tomorrow rhel7 Personally I think it is not worth reinventing the wheel.
workflow-tomorrow is unfortunately not open source.
So maybe we should make it open source. If there is some sensitive data it might be separated, I guess. CCing Petr and Lukáš to let them know.
(In reply to Dalibor Pospíšil from comment #10) > So maybe we should make it open source. If there is some sensitive data it > might be separated, I guess. > CCing Petr and Lukáš to let them know. Would you be able to give us feedback on this as soon as possible, since Matt is already working on finishing up the contributed patch. As Dalibor noted, it'll save us quite a bit of duplication.
Please do not wait on workflow-tomorrow. Of course feel free to get inspiration from there, internal stuff hidden in qe module. It would take some time to decouple it, until yesterday it wasn't even on the radar and priorities are elsewhere.
Dear Lukas, Cheers for the updated. We'll keep going with this one.
Sorry for the spam, there was a bit of confusion over milestones.
This went originally into develop (26.0) but we decided to backport it to release it ASAP, therefore back to 25.1.
Played around with: beaker-client 25.1 0.git.9.47e53f9c5.el6eng against beaker-devel Used some of the examples in the man page, as well as picked a job with a custom family. Result all ended up in correctly provisioned jobs and reservations. https://beaker-devel.app.eng.bos.redhat.com/jobs/14158 https://beaker-devel.app.eng.bos.redhat.com/jobs/14161 https://beaker-devel.app.eng.bos.redhat.com/jobs/14175
Beaker 25.1 has been released: https://beaker-project.org/docs/whats-new/release-25.html#beaker-25-1