[2.0b8] node network settings revert after failed bootstrap

[dann frazier]

I setup a new MAAS cluster (2.0.0-beta8), and attempted a juju (2.0.0-beta10) bootstrap:

ubuntu@maas:~$ juju bootstrap maas-controller maas
Creating Juju controller "maas-controller" on maas
Bootstrapping model "controller"
Starting new instance for initial controller
Launching instance
WARNING no architecture was specified, acquiring an arbitrary node
ERROR failed to bootstrap model: cannot start bootstrap instance: unexpected: ServerError: 400 BAD REQUEST ({"network": ["Node must be configured to use a network"]})

I inspected the node in the MAAS UI, found that all the interfaces were set to "Unconfigured", so I reconfigured one of the interfaces as "Auto assign". I then re-attempted the bootstrap, which failed do to a timeout. After juju released the node, I discovered that the network changes had reverted.

I posted a reproduction video here:
https://www.youtube.com/watch?v=bRQAZyT2Gxo

[dann frazier (dannf)]

ubuntu@maas:~$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-====================================-============-=================================================
ii maas 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS server common files
ii maas-dhcp 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS DHCP server
ii maas-dns 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS DNS server
ii maas-proxy 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS Caching Proxy
ii maas-rack-controller 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all Rack Controller for MAAS
ii maas-region-api 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all Region controller API service for MAAS
ii maas-region-controller 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0~beta8+bzr5134-0ubuntu1~xenial1 all MAAS server provisioning libraries (Python 3)

[Blake Rouse (blake-rouse)]

Thanks for the video that helped explain it more, but it would truly help if you could provide the output of the interfaces between each step.

maas my-maas-session interfaces read {node-id}

Also looking at the video it looks like the interfaces have the exact same name? That seems incorrect as the naming comes from the kernel when the machine is commissioned? Have you tried re-commissioning your machine to make sure the interfaces are correct. If they are incorrect that will affect your ability to correct deploy the machine.

[dann frazier (dannf)]

On Wed, Jun 29, 2016 at 7:42 AM, Blake Rouse <email address hidden> wrote:
> Thanks for the video that helped explain it more, but it would truly
> help if you could provide the output of the interfaces between each
> step.
>
> maas my-maas-session interfaces read {node-id}

I've since made several changes to my MAAS setup, and I can no longer
reproduce this.
However, I have seen it at least twice during initial MAAS setup - so
I don't think it's solar flares.
I'll be redeploying MAAS from scratch RSN. Assuming I can recreate,
I'll collect this.

> Also looking at the video it looks like the interfaces have the exact
> same name?

Just the same prefix - my window sizing has truncated it. They are
enP2p1s0f[1-3].

  -dann

[Andres Rodriguez (andreserl)]

WE believe this is no longer an issue. As such we are closing this bug report. If you believe this issue is still present on the latest version of MAAS< please re-open this bug report or file a new one.