maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

With reference to bug 1314267 [1] and bug 1274499 [2], we have a problem
where ISC DHCPD, when running low on unused addresses, hands out IPs
that are marked as reserved for a different host, or addresses that
appear to already be in use.

We've discussed allocating a smaller window of a cluster's overall
network range to dynamic allocation, but this is somewhat complex, and
can be swamped by, for example, LXC containers using DHCP to obtain IP
addresses for their bridged interfaces.

However, each cluster is meant to be on its own layer-2 subnet, so every
cluster could reasonably hand out link local addresses [3] from a (very
large) dynamic pool (and every cluster could use the same range, because
they're link-local and won't overlap). With some changes to MAAS [4]
this would be sufficient for enlistment and commissioning.

Then, when a machine is allocated to a user, an address can be chosen
from the cluster's configured network, and assigned statically to the
node by MAAS. This could be configured during node installation, or
added as a static host entry to the DHCP server (as now, except outside
of the dynamic pool), or both.

LXC containers would come up and obtain link-local addresses, which is
not going to be terribly useful. MAAS would have to provide an API by
which a node could obtain additional IP addresses. Juju, for example,
would be forced to obtain new IP addresses from MAAS when creating new
containers. [5]

What do you think?


[1] MAAS dhcpd will re-issue leases for nodes
<https://bugs.launchpad.net/maas/+bug/1314267>

[2] (dhcp lease rollover causes loss of access to managment IP
<https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1274499>

[3] http://en.wikipedia.org/wiki/Link-local_address

[4] Nodes are given a URL that points back to the region from which to
obtain their preseed, and they report commissioning results direct to
the region too. These would have to change to either be proxied via or
handled by the cluster.

[5] This API could be extended so that a user could obtain IP addresses
for use as VIPs by multiple nodes. These wouldn't be deallocated as long
as one or more of those nodes is still allocated.