Document that power-on for an acquired node deploys the machine

[Felipe Reyes]

[Impact]

MAAS provides an option to power on machines at user's discretion using "POST /MAAS/api/2.0/machines/{system_id}/?op=power_on", but MAAS is deploying the node instead of simply powering it on, so in practice there is no difference between op=deploy and op=power_on

[Test Case]

* Acquire a node
* power it on (example with output: https://pastebin.ubuntu.com/p/VMMkPVSBYC/ )
  $ maas maas machine power-on 8mxger

Expected result:
The machine is powered on and left to boot from the hard disk no matter what's in there.

Actual result:
The machine is deployed with its default configuration.

[Other info]

Related to the bug 1598275

[Björn Tillenius (bjornt)]

I agree. Having the power-on command to be a subset of deploy in some cases (i.e. when the machine is Allocated) is just confusing.

Although, to be fair, they don't seem to quite do the same thing. If I deploy a machine without any parameters, the UI shows "Deploy 18.04 LTS', and the deployment succeeds. If I power on an allocated node, the UI shows "Deploying /" and the deployment fails for some reason.

[Felipe Reyes (freyes)]

On Fri, 2019-01-18 at 09:47 +0000, Björn Tillenius wrote:
> I agree. Having the power-on command to be a subset of deploy in some
> cases (i.e. when the machine is Allocated) is just confusing.
>
> Although, to be fair, they don't seem to quite do the same thing. If
> I
> deploy a machine without any parameters, the UI shows "Deploy 18.04
> LTS', and the deployment succeeds. If I power on an allocated node,
> the
> UI shows "Deploying /" and the deployment fails for some reason.

In my case the deployment succeeds, I can ssh into it and '/' is
mounted on the physical disk.

--
Felipe Reyes
Software Sustaining Engineer @ Canonical
# Email: <email address hidden> (GPG:0x9B1FFF39)
# Launchpad: ~freyes | IRC: freyes

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[Felipe Reyes (freyes)]

MAAS version: 2.6.0 (7802-g59416a869-0ubuntu1~18.04.1)

terminal output exercising the reproducer of the bug's description: https://pastebin.canonical.com/p/vM3NBsJwbK/

[Blake Rouse (blake-rouse)]

This is expected behaviour. You cannot just power on a machine without it deploying. This would break the machine lifecycle and possible allow a user to get another users previous deployment.

You are correct that "power_on" is the same as "deploy" in the case that the machine has not yet been deployed. Once the machine has been deployed then "power_on" is different then "deploy".

[Felipe Reyes (freyes)]

I understand this operation could be restricted (for example to only admins) due to security reasons, but I still believe there could be valid reasons for someone to power-on a machine and attempt to access the data that it's in the disk(s) from an installation that maas is not aware of. The case that kicked off this bug was someone automating tasks in their datacenter (an Ubuntu Advantage user).

[Blake Rouse (blake-rouse)]

I see no use case for that, as the the cloud-init credentials place on the installed system would now be invalid and the system cannot talk back to MAAS at all.

For that use-case rescue-mode is what you want to boot, and from there you can mount the installed system if needed.

[Felipe Reyes (freyes)]

On Tue, 2019-09-24 at 14:28 +0000, Blake Rouse wrote:
> I see no use case for that, as the the cloud-init credentials place
> on
> the installed system would now be invalid and the system cannot talk
> back to MAAS at all.
>
> For that use-case rescue-mode is what you want to boot, and from
> there
> you can mount the installed system if needed.

ok, can we agree that "power-on" needs to be documented to inform users
that power-on will do a deploy if the machine's status is "allocated"?

[Dan Streetman (ddstreet)]

Additionally, does this mean that 'Allocate->Power On' does a deploy that's not actually logged in the event log?

[Blake Rouse (blake-rouse)]

Interesting about the event log, can you reproduce the behavior of no event log?

[Dan Streetman (ddstreet)]

> Interesting about the event log, can you reproduce the behavior of no event log?

no, sorry I misunderstood this bug; it's handled as a real deploy in the event log.

[Bill Wear (billwear)]

This bug has been open for a long time, with MAAS engineering's explanation that all this is expected behavior. There may be some doc nuances here, but not enough to warrant this bug. Closing, please re-open if you disagree, but make a strong case for what the doc should explain if you do, please.

[Igor Gnip (igorgnip)]

@Blake Rouse

There is a serious difference between powering on a machine (thus booting what is on the macihine)

vs

powering on a machine and seeing that maas wiped all user data and deployed empty os.

It is more than a bug.
Luckily, in our use case it doesn't seem to work that way because as soon as we get a deployment to succeed we cut the maas access to the machine.

This is because we do not agree with maas having the ability to wipe our data without a specific order of commands - release - secure erase - deploy.

power-on should just power on the machine.

If admins are concerned about booting what was previously on the machine - they should release with secure erase or quick erase.

I greatly value all your input but it just does not make sense to call action power_on and have it do anything except what it is name after.

[Igor Gnip (igorgnip)]

if the issue is about making a breaking change, I propose optional parameter to power_off

name: just_power_off
value: true/false
default: false

to preserve old functionality but solve the problem if anyone just wants to poweron the server.

Regards,
Igor