The new <reservesys/> element introduced in RFE #639938 allows systems to be reserved in a way that the scheduler is aware of. The "bkr system-release" command should be updated to also be able to release these systems, in addition to working for systems reserved via "bkr system-reserve". (They may be separate APIs on the server, but in that case, a common shortcut API that automatically does the right thing based on the current system state is still likely to offer a cleaner user experience in the client) This will still release the system by FQDN, even through there is an associated recipe ID. There are a few different reasons for this: 1. It maintains a consistent interface for releasing the system, regardless of how it was reserved. 2. The way to release a system reserved via reservesys is "ssh FQDN return2beaker.sh". This changes that to "bkr system-release FQDN" for systems reserved via the new mechanism. 3. When the "Reserve Workflow" is switched over to the new mechanism (see RFE #1102440) then the user may not even be fully aware that there is a scheduler recipe involved in the provisioning process. With the reservation changes, a separate "job-release" command that accepts a job/recipeset/recipe identifier may also make sense, but that would be a separate RFE.
Can we bump the priority to this? We would like to switch jenkins over to using this new reservesys mode and can't easily do it until we can extend and return early. Thanks
Beaker 19.1 sprint planning is next week, it should be possible to take a look at this one.
On Gerrit: http://gerrit.beaker-project.org/#/c/4265/
Verify steps: 1. create a job with <reservesys/> in a recipe. 2. Once the job status is "Reserved", use bkr system-release R:<recipe_id> or T:<recipetask_id> or system fqdn to return the system.
I would suggest the verification step also include returning the system from the test system itself...since we have return2beaker.sh when using the "reservesys" task.
(In reply to Amit Saha from comment #5) > I would suggest the verification step also include returning the system from > the test system itself...since we have return2beaker.sh when using the > "reservesys" task. Yeah, that's a fair point although there is no code change for this script.
(In reply to Amit Saha from comment #5) > I would suggest the verification step also include returning the system from > the test system itself...since we have return2beaker.sh when using the > "reservesys" task. This RFE is for beaker-client so it's not expected that you will be able to use this command on the test systems -- unless you first install the client, and configure it with suitable authentication etc. We're not planning to offer any equivalent to return2beaker.sh for <reservesys/>, mainly because the entire point of <reservesys/> is that it doesn't change the state of the system at all.
(In reply to Dan Callaghan from comment #7) > (In reply to Amit Saha from comment #5) > > I would suggest the verification step also include returning the system from > > the test system itself...since we have return2beaker.sh when using the > > "reservesys" task. > > This RFE is for beaker-client so it's not expected that you will be able to > use this command on the test systems -- unless you first install the client, > and configure it with suitable authentication etc. Right, but it is a potential use case, especially if someone is looking for a command line equivalent of "Release System" from the Web UI.
This was actually included in the 20.2 bug fix release.