[Maas-devel] RFC: "Serialising" power actions

[Dean Henrichsmeyer]

On Tue, Sep 16, 2014 at 6:43 PM, Julian Edwards <
julian.edwards at canonical.com> wrote:

> On Tuesday 16 Sep 2014 11:42:48 Gavin Panella wrote:
> > On 15 September 2014 22:34, Graham Binns wrote:
> > ...
> >
> > > 1: The current power action blocks all others until it as completed.
> Other
> > > power actions will be queued and executed in turn.
> > > - or -
> > > 2: Each power action supersedes any action that is currently executing
> —
> > > the existing action is cancelled and then the new action is run.
> > > - or -
> > > 3. We track the current ("now") and "next" actions for the node, but
> drop
> > > every action that comes in once those two slots are full.
> >
> > I think #1 is wrong; apart from stress-testing I can't think of a
> > situation where I'd want every panic-and-frustration-induced click of
> > the power buttons in the UI to be recorded and acted upon. I just want
> > it to do the last one.
> >
> > #3 is like #2, but you have to wait for the currently executing command
> > to finish. Boring!
> >
> > I think #2 is the right starting point. In addition:
>
> I disagree.  You'll be back in the scenario where important power ops are
> ignored (and is a bug that I just fixed).
>
> For example, a machine is slow to power down and doesn't finish before a
> power
> up is issued. MAAS expects the node to have rebooted, but in fact it hasn't
> and at best will sit there not doing anything, at worst will reboot with
> old
> data.
>
> Effectively you've issued two power commands both of which were ignored.
>
> We *must* wait for an outstanding power op to finish one way or another,
> whether it fails or it succeeds.
>

Agreed. As stated, you can't really cancel an executed command in a
meaningful way so any solution that has canceling as part of the process
doesn't make sense to me.

-Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20140916/5c74ab0a/attachment.html>