[2.0b4] After commissioning, subnet lists 'observed' IP address for machines

[Andres Rodriguez]

I commissioned a whole bunch of machines, and after it compelted, MAAS showed 'Machines' with 'Observed' IP addresses but machines are now off.

[Mike Pontillo (mpontillo)]

The observed addresses will most likely remain in the system as long as the DHCP lease has not expired. What is the state of the DHCP leases database when you see the observed addresses?

[Andres Rodriguez (andreserl)]

My point for the bug is that commissioning should release the IP a address
at the end of it!

On Tuesday, May 3, 2016, Mike Pontillo <email address hidden> wrote:

> The observed addresses will most likely remain in the system as long as
> the DHCP lease has not expired. What is the state of the DHCP leases
> database when you see the observed addresses?
>
> ** Changed in: maas
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1577960
>
> Title:
> [2.0b4] After commissioning, subnet lists 'observed' IP address for
> machines
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1577960/+subscriptions
>

--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

[Mike Pontillo (mpontillo)]

The MAAS team discussed this today; we feel like since cloud-init is responsible for configuring the interfaces to DHCP, and is responsible for sending the last status message to the network before powering off the system, cloud-init should be responsible for running "dhclient -r <interface>" for each interface it configured for DHCP.

We would most likely want a boolean we could set in the cloud-init configuration which would cause this behavior to occur; we would only want to release the IP address when we're booting the system ephemerally. It seems possible that we would inadvertently cause regressions with some integrations if cloud-init unconditionally released its IP addresses. What do you think?

[Blake Rouse (blake-rouse)]

This seems like a very strange thing that cloud-init should be doing. Maybe for the first interface that MAAS brings up it makes since for cloud-init to do, but all the other interfaces are brought up by the MAAS commissioning scripts. That process is a direct process as well and does not place any information in /etc/network/interfaces for Ubuntu to even know that those IP addresses should be released.

Also their is the matter of getting this into cloud-init and having it work across trusty+. It should be rather simple for the MAAS commissioning script to inject a poweroff script that will be ran at the very end of the shutdown process to release all IP addresses on interfaces.

[Mike Pontillo (mpontillo)]

Blake, I looked at commissioningscript.py in MAAS 2.0 and it doesn't look like MAAS is bringing up dhclient any more. (it looks like we're leaving this in the hands of cloud-init?)

In MAAS 1.9 I see the code that calls `dhclient` on all the interfaces, however.

[Newell Jensen (newell-jensen)]

Looks like the equivalent code was moved to provisioningserver.refresh.node_info_scripts in the dhcp_explore function.

[Newell Jensen (newell-jensen)]

Additionally, I only see this issue showing up using trusty commissioning images. I do not see this issue using xenial images using a VM with one interface.

[Newell Jensen (newell-jensen)]

We are setting this to incomplete because we no longer think this is an issue.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2665