maas-devel team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 15/07/14 04:54, Andres Rodriguez wrote:
> Hi Julian,
>
>> The original design (as discussed on this list and design docs) was not to
>> do
>> this, but to give an IP when allocating the node to a user.  This was so
>> that
>> (in the future) users can say things like "I want to use this VPN/bond IP"
>> etc
>> right from the start without wasting another IP.  It's very hard for MAAS
>> to
>> be able to change the IP on demand for a machine that is already booted
>> unless
>> we go down the Azure road and run a MAAS agent on the nodes.
>>
> I do agree with you that it is very hard to change the IP on demand, and
> this should not be considered as part of the DHCP work.
>
>> There is a separate mechanism to permanently assign an IP to a node if the
>> admin wishes (the API for that is not coded yet but the underlying basics
>> are
>> in place).  Is this what folks want now?
>>
> I think that this is indeed something we want to be able to do. I think it
> is important for us to be able to assign an IP to a node's MAC address, so
> that when we configure things like bonding (in the future, or manually), we
> could choose what interface will be the default or the one answering ARP
> requests for the bond. We should be able to do this without even having the
> machine allocated to a user. (Only an admin should be able to do this).

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.


>>> On Sat, Jul 12, 2014 at 9:55 AM, Mark Shuttleworth <mark@xxxxxxxxxx>
>> wrote:
>>>> I would suggest that once MAAS "owns" a machine, i.e. MAAS has PXE
>>>> booted the machine itself (credentials work), it is given a name and
>>>> static IP address which does not change unless edited by the user (it
>>>> should be possible for the user to put it on a difference, unused IP
>>>> address in the static range). Renaming the machine would update DNS,
>>>> editing the IP would update DNS.
>>>>
>>>> This allows a user to "ping" a machine and see that it is off.
> I see benefits/advantages on doing this:
>
> 1. Having machines with pre-allocated addresses makes maintenance easier.
> Nodes will always have a DNS/IP address mapping, allowing the administrator
> to know IP addresses before hand, which eases maintenance.

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?

> 2. Allows for network enumeration / mapping between machines, DNS names,
> MAC and IP addresses. (Allows administrators to select the interfaces to
> use for things like bonding, if the IP is assigned to an specific MAC)
> 3. MAAS will do less updating of DNS/DHCP mappings every time machines are
> powered on/off. At scale, we expect that many machines would be powered
> on/off, and having to update mappings when this happens might become costly
> (As an example, one of the drivers of DHCP changes was the fact that celery
> would consume 100% CPU when parsing DHCP leases, because they were read on
> real time. With this this wouldn't be the case as IP address would be
> previously defined and would not change unless done by the administrator).
>
> Disadvantages
>
> 1. This is not a cloud-like approach.
> 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).

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 :)


>> We can do this as things stand because if a user still "owns" a machine, it
>> retains the static IP given at startup time.
>>
>> Or to put it another way, a machine that is supposed to be up will always
>> have
>> an IP.  If you want to see whether it's really up or not we should
>> probably do
>> an API call to examine the power status (on the BMC); then if it's still
>> not
>> pingable you know there's a more serious problem.
>>
> I think that we can keep the current approach on how MAAS is assigning IP
> addresses, however, as briefly discussed via IRC with Julian, we can have a
> Setting option that would change this approach to basically do the
> following:
>
> 1. Pre-allocate IP address to nodes that have successfully "commissioned".

Yes, I think this is useful behaviour as a default.

Remember, we are going to have to deal with much more interesting
scenarios in the future:

 * multiple IP addresses per machine (aliases, bonding, vlans, ipv6)

So generally, thinking of IP's as a resource that MAAS manages is
correct, and being able to manipulate the model as to which IP addresses
belong to who and where, is to be expected.


> 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.

In cases where a service like Landscape has reserved IP addresses,
either just taking them and configuring them statically itself, as in
the floating IP case, or possibly by asking MAAS to provide DHCP for
that address to a particular MAC, then that same service should be able
to come along and reassign the IP differently, releasing it back to
Landscape or changing the MAC / IP for DHCP.

> 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.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature