Comment 7 for bug 1807991

I don’t think there should be a new state, because the reality is that the
machine has enlisted and registered itself (hence its set as “New”), and
the “auto-commissioning” happens, which is in fact the machine is
commissioning (hence set as commissioning), but since it is automatic, the
machine is set back to “New”.

That said, I think then that the best solution is to have a global option
that allows you to disable “auto-commission” right after enlistment.

On Tue, Dec 11, 2018 at 12:45 PM Jason Hobbs <email address hidden>
wrote:

> 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
> >
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1807991
>
> Title:
> Commission is not available because of the current state of the node.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1807991/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=maas; milestone=2.5.1; status=Triaged;
> importance=Medium; <email address hidden>;
> Launchpad-Bug-Tags: cdo-qa foundations-engine
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl jason-hobbs
> Launchpad-Bug-Reporter: Jason Hobbs (jason-hobbs)
> Launchpad-Bug-Modifier: Jason Hobbs (jason-hobbs)
> Launchpad-Message-Rationale: Subscriber (MAAS)
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer