In previous releases, machines that auto-enlisted went to 'New' state and
stayed there. A client could see a newly auto-enlisted node in 'New' state
and safely issue a 'commission' command without worrying about getting an
error back. That means a client that correctly used the API in 2.4 may get
an error back in 2.5, using the exact same sequence of reads/writes. That's
what makes it an API breaking change.

I think 'Commissioning -> New' is much better than 'New -> Commissioning ->
New'. In the latter, 'New' is used for two different states and creates a
race with clients issuing the commissioning operation. When we see a node
in 'Commissioning' we know we can't do anything with it, except wait for it
to finish 'Commissioning'.

Even that is a bit weird though, because usually after 'Commissioning' we
go to 'Testing' or 'Ready'.  This feels like a different state to me -
'Enlisting' maybe. However, I'm not sure how a client would react
differently to the two states.

On Tue, Dec 11, 2018 at 11:25 AM Andres Rodriguez <email address hidden>
wrote:

> It is actually not breaking API compatibility because it is intended
> that the machine is 'newly' registered (sets status to 'NEW'), the
> machine is automatically commissioned (sets status to 'Commissioning'),
> and once it is finished, it will be set back to 'New'. Hence, the
> machine will remain in new.
>
> We can explore to see if it would be possible to always go from
> Commissioning -> New without going from New -> Commissioning -> New and
> fix that for 2.5.1.
>
> Thoughts?
>
> ** Changed in: maas
>     Milestone: None => 2.5.1
>
> ** Changed in: maas
>        Status: New => Triaged
>
> ** Changed in: maas
>    Importance: Undecided => Medium
>
> ** Changed in: maas
>      Assignee: (unassigned) => Lee Trager (ltrager)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1807991
>
> Title:
>   Commission is not available because of the current state of the node.
>
> Status in MAAS:
>   Triaged
>
> Bug description:
>   When using FCE, we wait for nodes to enlist and show up in NEW state,
>   rename the machine, update some tags, then we issue a command to start
>   commissioning.
>
>   That failed for one node in 2.5.0 rc2 with this error:
>
>   2018-12-11-08:55:49 root DEBUG maas root machines read
>   2018-12-11-08:55:53 root DEBUG maas root machine power-parameters nprfpk
>   2018-12-11-08:55:55 foundationcloudengine.layers.maaslayer DEBUG
> Commissioning geodude
>   2018-12-11-08:55:55 root DEBUG maas root machine update nprfpk
> hostname=geodude zone=default
>   2018-12-11-08:55:58 root DEBUG maas root tag read foundation-nodes
>   2018-12-11-08:56:00 root DEBUG maas root tag update-nodes
> foundation-nodes add=nprfpk
>   2018-12-11-08:56:02 root DEBUG maas root machine commission nprfpk
>   2018-12-11-08:56:05 root ERROR Command failed: machine commission nprfpk
>   2018-12-11-08:56:05 root ERROR {"__all__": ["Commission is not available
> because of the current state of the node."]}
>
>   At 2018-12-11-08:55:49 the machine was in NEW state. We didn't issue
>   any commission commands until 2018-12-11-08:56:05.
>
>   According to the maas logs, it looks like after we read NEW state and
>   before we started commissioning, the machine transitioned to
>   COMMISSIONING state on its own without us telling it to:
>
>   10.244.40.32/var/log/maas/maas.log:2018-12-11T08:55:51+00:00 leafeon
>   maas.node: [info] whole-mule: Status transition from NEW to
>   COMMISSIONING
>
>   This is with 2.5.0~rc2-7433-gea48d302e-0ubuntu1~18.04.1
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1807991/+subscriptions
>