maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 18 Sep 2014 13:33:00 Gavin Panella wrote:
> We can implement desired-power-state as a direct inference from status
> or by using additional intermediate steps, it doesn't really matter. My
> point is that the desired power state is quite strongly related to the
> node's place in its lifecycle, to the point where we don't need to store
> a separate desired-power-state.

Ok we'll have to agree to disagree on that one :)

> 
> However, you think that we should be in control of power state when a
> node is deployed, and I can see we'd need a field for that, but I think
> the consensus so far is not in favour of that.

Right, I think this area is not specified well enough to make an 
implementation decision.

I don't mind if we leave the power "unmanaged" when DEPLOYED but we do need to 
reconcile the fact that users on the machine can power it off, MAAS can turn 
it off and on and someone can even flip a switch to turn it on.  As long as 
we've considered how these might all interleave and make sure the code doesn't 
do anything untoward, it's all good.

> For BROKEN nodes, where we want to allow debugging, we can say something
> like "power-off at first, then expect it to be off, but don't enforce".
> Whereas a machine the READY state would be "expect it to be off, and
> enforce".

Well my point was that if it's BROKEN, we don't want to do *anything* on that 
node, because it might be the power that's broken.  Generally, BROKEN really 
means "do not touch me, in case I want to debug this".  Issuing a separate 
power down after marking it BROKEN if you know power works is fine, I think.

J