[Maas-devel] MAAS IP Allocation [was: Re: 1.6.0 beta 4 out]

[Julian Edwards]

On Tuesday 15 Jul 2014 14:04:07 Mark Shuttleworth wrote:
> The important attitude is to say "IP addresses are a resource that MAAS
> manages itself". So, rather than MAAS only providing services on the
> range we tell it to, MAAS needs to be able to provide services on all
> the OTHER IPs on the networks it is managing.
> 
> By that I mean:
> 
>  * DHCP for unmanaged machines ("my switch management IP is X.y.z.a")
>  * ability to reserve and release IPs for things like Landscape to use
>        ("Landscape has asked for these IPs on this network to statically
> configure")
> 
> ... and DNS likewise.

This is all well understood (at least by me) after our recent thread on this 
ML.  There is already an API in place in 1.6 for IP reservation.

The model changes support the other requirements, but they are not implemented 
yet.

> By "always" we mean "until a user decides to reassign the IP or remove
> the association". In other words, the principle is least surprise:
> 
>  * if a machine is at an IP it stays there
>  * until a human says to do otherwise
> 
> Make sense?

I guess it depends on how the admin views his nodes.  If we treat it as a true 
cloud-like resource, then assigning IPs on demand makes more sense to me.  
When a resource is not allocated, it doesn't need any IP.

However, I suspect that shifting traditional attitudes towards this thinking 
in the data centre will be tough, and the pre-allocation of IPs becomes more 
familiar for those people.

The remaining problem with this is that if an IP is pre-allocated, and then 
the user comes along and says "I want to use this IP I reserved earlier 
please", what should happen to the old IP?  Do we put it back in the pool?  Do 
we shelve it until the node is released?

Additionally, with pre-assigned IPs, should we do that for every interface the 
node has?

> > 2. We will be using IP address of a network range even if machines are
> > powered off.
> 
> Yes, I see this point, and I think it makes sense to have the ability to
> say that some machines or IP addresses are harvested automatically, for
> use in very large environments (so a human doesn't have to do the work).

Right, see my questions above :)

> The problem we have, from a user experience point of view, is that most
> initial MAAS deployments are small, and if the behaviour of MAAS is
> surprising or unpredictable or awkward for those small deployments then
> they will never become BIG deployments :)

I'm still not sure which of pre-allocation versus doing it on the fly is the 
least surprising.

Before this recent change of mine to add true static IPs, nodes did not have 
an IP until they booted because MAAS had to wait for the DHCP server to 
respond to the node's request(s), at which point we assign the DNS entry.  
Then after the node switched off, the IP lease expires at some point in the 
future and the machine loses the IP and thusly its DNS entry.

Therefore I could argue that continuing this "IP on boot" approach is the 
least surprising based on previous behaviours!

I'd love to get some more feedback from real users here.  James, do you have 
any opinions?

> > 1. Pre-allocate IP address to nodes that have successfully "commissioned".
> 
> Yes, I think this is useful behaviour as a default.

I'm happy to add a configuration setting for this behaviour and default to 
pre-allocation.  But I think we first need to decide what happens if a user 
wants to override the pre-allocated IP.

> > 2. Change the IP allocation to a different MAC address or a different IP
> > address, allowing DNS mapping to be updated without having the allocate /
> > turn on the machine.
> 
> In cases where an IP address was handed out to then be written
> statically, yes, we cannot simply reallocate the address. For example,
> if I've said that I've configured a switch to have a management IP on a
> particular address then it's clear a human has to reassign the address.
> 
> That said, if we're getting DHCP request from that MAC for that address,
> then it would be safe to assume we can answer those requests with a
> different IP and whatever is asking for the IP will accept a new one. At
> least, if a human says "answer DHCP for that switch to give it a new
> address" then we can confidently do just that.

This implies we might need a configurable lease time (perhaps also class-
based?) so that admins can expect this to happen expediently.

We can't do DNS updates based on this though, of course.

> > 3. We could potentially allocate multiple IP's to a node, each one to a
> > different MAC addresses.
> 
> Worse - multiple IPs to a single MAC address. Aliases are exactly that,
> and need to be supported.

The model already has support for aliases.

IPv6 is going to be fun though, as the user-space for the kernel 
implementation gives you multiple IPs on the same interface with no aliases.

J
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20140716/d2033dbb/attachment.pgp>