maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 15 Sep 2014 17:26:19 Tycho Andersen wrote:
> On Mon, Sep 15, 2014 at 07:17:54PM -0300, Christian Robottom Reis wrote:
> > On Mon, Sep 15, 2014 at 03:12:58PM -0700, Newell Jensen wrote:
> > > Some fodder:
> > > Just from a UI standpoint - Isn't there a way we can limit this so that
> > > the
> > > UI is disabled and a power action 'button' wouldn't become enabled until
> > > the blocking power action was performed?
> > 
> > That would make the UI more sensible -- power actions could trigger a
> > spinner and then complete successfully or fail.

The UI already blocks power operations unless the node is in the right state, 
but you can't apply that solution to the API.

The problem is that it arrives at the wrong state at the wrong time because 
the power control code is currently naive.

> But I don't use the UI. If my power commands get rejected because "You
> need to wait longer to complete a power action.", I'm going to be less
> than happy :). To me, GMB's suggestions of either queuing things or
> cancelling things seem to be the ones that pass the principle of least
> surprise.

If the state is correct and one that cannot receive new power operations, then 
your power command will/should get rejected.

> Queuing them would also be ok from my point of view, but probably more
> work than it is worth. Option 3 is just a special case of this, but if
> you're going to do it, you may as well just queue them all.

Queuing them up is a terrible solution, as we found when using Celery before 
adding a deadline to the tasks.  They can pile up and cause a node to flip-
flop.

J