[1.9] MAAS can auto-assign a known default gateway for a subnet to a deploying node.

Setting this back to invalid provided that it is possible to reserve IP's:

https://docs.ubuntu.com/maas/1.9/en/static-ips#unmanaged-user-allocated-ips

So, to be clear, MAAS allocated the IP of the default gateway of the rack controller. You should not have to tell MAAS not to shoot itself in the face.

Wait, if this happened in MAAS 1.9, doesn't that mean that the static range on the cluster interface includes the gateway IP?

We having existing bugs open for the same, or similar - LP: #1569683 and #1600249.

@Haw,

Those bugs are not the same. This bug refers to managed subnets auto-assigning the gateway IP for a known subnet.

LP: #1569683 talks about unmanaged subnets, and providing a static IP on an unmanaged subnet.
LP: #1600249 Prevents the user from assigning an IP. Through the comments, this is related to the UI not surfacing an error saying that the IP address is already in use.

@Mike,

The issue seems to be that MAAS is providing the gateway IP as an auto-assigned IP for a subnet that has the gateway IP set. In other words, MAAS is not pre-reserving such IP.

    MAAS did not start pre-reserving IP addresses until MAAS 2.0. MAAS 1.9
expects the static range to be under the complete control of MAAS.

In MAAS 2.0, the concept of a "static range" was removed; without that
explicit knowledge of which IPs were intended for allocation by MAAS, MAAS
learned to cope by excluding "special" addresses such as gateway IPs, DNS
servers, and interfaces configured on the MAAS servers themselves.

There are a couple ways I can think of we could address this in MAAS 1.9:

(1) Validate when saving a cluster interface that the static range doesn't
include the gateway IP.

(2) Change the IP allocation code to mimic the behavior of MAAS 2.x.

Both potential changes might not solve the entire issue, which is that MAAS
does not have complete information about the network. That is, if the user
didn't fill in the default gateway on the cluster and interface definition
page, MAAS 1.x has no idea what address it should avoid.

For the record, support for exclusion of gateway IPs was added in revision 4657 for inclusion in MAAS 2.0, as part of IP range enablement work.

I'm proposing a simpler version of (2) which doesn't attempt to backport all the new smarts in MAAS 2.x.

@andresrl, to my knowledge this bug was created as a result of an outage on an unmanaged subnet, and there's nothing in the description which suggests it refers to managed subnets. This leads me to the conclusion that it is the same problem as #1569683.

To me the core issue in both bugs is that MAAS seems to depend on its own configuration to determine which addresses are in use, rather than using the operational state of the network. The latter should be determined through the use of ping and/or the ARP table.

@paulgear, MAAS uses the operational state of the network starting in version 2.1, but this bug was filed against MAAS 1.9.

@mpontillo, yep; so I guess the question is: does the "simpler version of (2) which doesn't attempt to backport all the new smarts in MAAS 2.x" include the smarts to use ping and/or ARP tables?

@paulgear, no, that type of change is out of scope and too risky to add to a maintenance release of MAAS. The change I proposed relies on the subnet's configured gateway IP to be correct.

Related? https://bugs.launchpad.net/maas/+bug/1546301