Description of problem: We have lost the ability to "Take" a system once it has been "Loaned" to us. I understand that a user that has group ACLs on the host can set the system to "Manual" which then allows them to "Take" it. However, this causes problems for those that do not have group ACLs and need troubleshoot with the target host. When troubleshooting issues one need be able to run automated jobs (the power of the loan option) as well as provision the host without concern of a 'reserve time window' (the power of the take option). Without the ability to "Take" one may likely lose work performed on the host, as the 'reserve time window' could elapse and the system be reinstalled via a new job that was in queue. Version-Release number of selected component (if applicable): Version 0.15.0 Actual results: We have lost the ability to "Take" a system once it has been "Loaned" to us. Expected results: Ability to "Take" a system once it has been "Loaned" to us. Additional info:
Loaned systems are not made available for use by other users through the scheduler, even when in Automated mode. Clicking "Take" was redundant in this case and has been removed from the UI accordingly. The Take step is used solely to set the system user in the Manual case. This allows usage to be indicated without necessarily having to provision the system through Beaker. Further adjustments to the loans and reservations mechanism are currently being designed for Beaker 0.16, as described in http://beaker-project.org/dev/proposals/improved-reservations-and-loans.html (Note: that design proposal is currently quite developer centric. It will be updated to describe the expected interface for users prior to acceptance)
On further analysis, we realised the missing feature is that in Beaker 0.14, taking a loaned system made it possible to carry out a manual provisioning operation even if the system was configured for Automated mode. The disadvantage of only permitting provisioning through the scheduler in this case is that you *must* specify a time limit, and having a system loaned to you doesn't grant the ability to switch the system to Manual mode. While bringing back the "Take" button isn't necessarily the right answer, there *should* be a way to provision a loaned system without an automated time limit.
The other similar capability is setting the release action for a system to "LeaveOn". However, that's not an acceptable alternative as: 1. It permanently alters the behaviour of the system (whereas manually reserving an automated system has no further effects once the reservation is returned) 2. It's only available to users with access to edit the systems settings (which isn't granted by having the system loaned to you) That suggests restoring the ability to manually reserve automated systems is the simplest available answer.
(In reply to Nick Coghlan from comment #4) > That suggests restoring the ability to manually reserve automated systems is > the simplest available answer. But if you've manually taken an automated system you will also want some way of provisioning it, which means the Provision tab has to go back to provisioning immediately instead of scheduling a new job. That leaves us right back where we started with bug 855333, which is that the Provision tab does different things depending on a very complicated set of rules which tend to surprise users in bad ways. My solution in bug 855333 was to make the Provision tab vary its behaviour only according to the status of the system and nothing else. But I suspect the right answer is that the Provision tab should *always* immediately provision a machine (and it would only be available when you are the user of the system), and if you want to schedule a job on the system use the Reserve Workflow instead. The main thing missing is that "just using Reserve Workflow instead" is not so simple. We have the nice UI for picking your distro, but the whole thing is structured under the assumption that you pick your distro *then* your system, not the other way around.
Right, it's a little messy, but I think it's the easiest way to ensure we don't lose functionality in 0.15 relative to 0.14. The change I'm proposing here is that when the system is Automated *and* loaned to somebody: 1. The Take button will be displayed for that user 2. The Provision tab will have a note at the top indicating that they should reserve the system in order to switch to manual provisioning The difference between Automated and Manual mode is then that: - in Automated mode, the Take button only appears for a user that already has a loan in place, whereas in Manual mode it's visible to anyone that can reserve the system - the "Schedule Provision" panel only appears for systems in Automated mode Once the reserve workflow has better support for provisioning specific systems, then the "Schedule Provision" panel could indeed be replaced with a note to use that instead. However, that's more a topic for the reservation and loan changes in 0.16.
I think I agree with your proposal, but let me re-state what I think you said. :-) If a system is loaned to me I will see the following: - The take button will be visible - The provision tab will allow me to Schedule a provision - The provision tab will also state that I can take the system to do a "manual" provision. When I take the system I will see the following: - The provision tab will allow me to do an immediate provision. The only thing I would like to see improved is to *only* show this immediate provision if there isn't an active job. An active job would would still show the schedule a provision tab. I've seen multiple users accidentally re-install a running job when they have a system loaned to themselves. They thought they were scheduling another job to run *after* the current one.
Not quite. If the system is currently running an automated job, the Take button won't be visible, and if you've taken the system, scheduled jobs won't run until you return it. So we shouldn't be able to get into the situation where the user has taken the system *and* it is currently running an automated job. However, I'll look into displaying a slightly different message on the Provision tab based on whether or not the system is currently free.
(In reply to Bill Peck from comment #7) > I've seen multiple users accidentally re-install a running job when they > have a system loaned to themselves. They thought they were scheduling > another job to run *after* the current one. This is the exact problem in bug 855333 so I agree it's important we not go backwards on it now. (In reply to Nick Coghlan from comment #8) > Not quite. If the system is currently running an automated job, the Take > button won't be visible, and if you've taken the system, scheduled jobs > won't run until you return it. So we shouldn't be able to get into the > situation where the user has taken the system *and* it is currently running > an automated job. I think we need to be clear on terminology here... When a user "takes" a system using the Take button, system.user is set and a reservation row is created with type='manual' (the method is reserve_manually). When the scheduler picks a system for a recipe, it essentially "takes" the system for that user: it sets system.user and creates a reservation row with type='recipe' (reserve method). The end result looks almost the same on the system page, the only indication given that a system was reserved by the scheduler (apart from activity logs) is the presence of a "Current Job" link next to the user. So what we are proposing on this bug is: * A user can manually reserve an Automated system iff it's free and it is loaned to them. (I still think allowing manual reservations on Automated systems feels wrong, but that's a bigger issue to be tackled separately.) * The Provision tab will provision immediately if the system is set to Manual, or if it is set to Automated and the reservation type is manual. It will schedule a new job if the system is set to Automated and is not reserved, or if the reservation type is recipe. (That means we still have the Provision tab altering its behaviour based on some very subtle and complicated conditions, which is poor user experience and the cause of accidents as in bug 855333, but at least the conditions should be less subtle and less surprising than they were previously.)
That sounds right. I also plan to try to make the behaviour less surprising by including appropriate messages in the Provision tab for the different states. This kind of text already exists in 0.15 for cases where the user cannot reserve the system, or where they need to reserve a Manual system before provisioning it, but this patch will introduce more cases that could do with clarification. (These messages will be displayed above the provisioning UI in cases where provisioning is allowed, either directly or through the scheduler) My current draft messages: User does not have access to reserve the system: "You do not have access to provision this system." Currently reserved, user no longer has access to reserve: "After returning this system, you will no longer be able to provision it." Automated system, user does not have it reserved and has access to reserve it: "Reserve this system to provision it directly rather than through the scheduler." Automated system, user has it manually reserved and still has access to reserve it: "Return this system to provision it through the scheduler rather than directly." Manual or Broken system, user does not have it reserved and has access to reserve it: "Reserve this system to provision it." No text will be displayed for the case of a Manual or Broken system where the user already has it manually reserved.
Ah, I realised I still didn't quite have the conditions correct. The two "Automated system" messages shown only apply if the system is currently loaned to that user. There needs to be a separate message for the "automated and not loaned" case: Automated system, user does not have a current loan and has access to reserve it: "Borrow and reserve this system to provision it directly rather than through the scheduler." The challenges of bringing order to combinations of multiple options :)
On Gerrit: http://gerrit.beaker-project.org/2349
As discussed in the Gerrit review, we ended up changing the exact wording of the UI text from that given in the comments above, but the general behaviour described in comment 9 has been implemented.
While the submit button label was correctly changing for the different modes, the provisioning options and the actual requested operation were still controlled only by whether or not the system was in automated mode rather than whether or not a manual reservation was in place. Updated patch on Gerrit: http://gerrit.beaker-project.org/#/c/2367/
beaker 0.15.1 has been released.