Excerpts from Nick Coghlan's message of 2014-02-27 14:50:44 +1000:
Just noticed a bug: if you associate a system with a lab controller, you need to refresh the page to update the power settings tab. I expect that's just the known problem with it not being a Backbone widget, though.
Right. I just put up a patch to port the power settings widget to Backbone: http://gerrit.beaker-project.org/2865
Ah, I just realised that one benefit of the new vertical layout for the tab list is we can make the titles a bit longer, and splitting a tab is less of a problem. So, here's my suggestion.
- Move the full command queue out to its own "Command Queue" tab under
history
The advantage of showing the queue on the same page as the buttons is that pressing a button triggers a new command to show up in the queue as "Queued". It's a nice instant feedback to indicate that the button press really did something, and it means we don't have to resort to notification saying "yes we really enqueued your command".
Also I imagined one day in the future we could do EventStream (or even just regular polling) to refresh the command queue state, so that you can hit the Reboot button, a queued command appears, and then a few seconds later your command changes to Completed.
So I think we are better off keeping the command buttons and the queue together.
- Rename the existing Power tab as "Power Settings"
It's called "Power Settings" in 0.15, I had renamed it to just "Power" for the new system page because I introduced the tab groupings. That one is grouped under "Configuration" so the word "Settings" seemed redundant. But looking at it again, I think "Power Settings" is reasonable, and should reduce confusion. Same thing applies to "Scheduler [Settings]".
- Rename the Commands tab as Power
Now, to justify the presence of "Clear Netboot" on the Power tab, I suggest we do the following: report some basic "last known state" information on the Power tab, specifically enough so users know what's likely to happen if they reboot or power on the system.
As an initial version of this, two relatively simple to calculate values that seem useful:
Last netboot configuration: Provision <distro> or Cleared (Boot Menu) Last power status: On or Off
So then the purpose of Clear Netboot is to get the boot menu when you power on the system.
We can definitely show the current netboot status, and I guess it does justify having the Clear Netboot button there even when the tab is named "Power".
I would hesitate to show the power status because it might give unrealistic expectations -- the power can easily be controlled outside of Beaker (simplest example: run shutdown) so there's a very high chance if we claim the system is on or off, that it really won't be.