Excerpts from Marian Csontos's message of Tue Jan 31 17:40:45 +1000 2012:
Could we squeeze the queued calls (except the pending one) into one?
- Reboot+Reboot -> Reboot
- Reboot+Power-off -> Power-off
- Reboot+Power-on -> Reboot
- Power-off+Power-on -> Reboot
In some case we can include pending call in the game as well:
- [Reboot] + Reboot -> [Reboot]
- [Reboot] + Power-on -> [Reboot]
Looks like a simple filter would do...
We could add some logic on the server side to optimise the queue when
new commands are added. I don't think the beaker-provision daemon needs
to worry about this. However if we are removing/altering commands on the
server side while they are queued, we have to be careful not to
introduce a race between the time beaker-provision fetches the command
and starts running it.
I don't think the scheduler will ever enqueue consecutive power
commands, except if a system is powered off at the end of a recipe and
then immediately rebooted for the next recipe. That becomes the same as
power off + power on, which for most power types is equivalent to a
reboot. So I don't think there's much to be gained for the scheduler.
However a user could manually queue up lots of power commands using the
web UI -- in that case, maybe we should honour them even if they make no
sense (such as power on + power off, or reboot five times, or similar)?
Is there any reason why someone would want to enqueue multiple power
commands, apart from "I am impatient so I will mash this button"? A
better approach would be to add some sanity checking in the web UI, or
else just assume the user knows what they are doing and honour it.
From my side just one thing: is Provisioning in the same queue as
This affects Answers to following two Quesitons:
- When does beaker see the machine as free?
- When is PXE boot on LC set?
Both should happen only after previously queued power-commands complete
and the one issued by caller succeeds.
If not, imagine following:
[Impatient user here]
[Watch, nothing's going on]
[Watch for a bit longer]
Return the machine to beaker
Beaker schedules recipe, sets PXE boot on cobbler,
and now the sequence of reboots would take place instead of the job...
Right now configuring netboot is done synchronously, but power commands
(including reboot for provisioning) are done asynchronously through the
command queue. So the scenario you describe is possible right now.
We've already agreed that this is not ideal, and that provisioning
should be done through the command queue to avoid those kinds of
problems. That will be happening for the Cobbler removal effort (or even
Dan Callaghan <dcallagh(a)redhat.com>