maas-devel team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 22/05/14 12:41, Gavin Panella wrote:
> On 22 May 2014 08:18, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
>> MAAS needs to become a semi-DHCP server by allocating IPs in the static
>> range.  Therefore the following tasks spring to mind.  Please review and
>> let me know if you have any others:
>>
>>  * DB model changes
>>   * high/low static range
> I think we record this already.
>
>>   * pool of allocated IPs (need to think more how to model this one)
> At some point I think we want to be able to assign IPs to a *user*
> rather than a *node* as well, to allow for floating VIPs. A table of
> (user, optional-node, address) would allow us to model it I think.

Please don't pre-assign IPs to a user. We DID discuss being able to add
arbitrary nodes to the database, it would be entirely in keeping with
this to allow the user to specify an IP address for a particular machine.

> However, we also need to consider how to project these addresses into
> DNS. I've tried to answer my own questions below:
>
> * Should each record also have a hostname associated with it?
>
>   -> Yes.
>
> * Should we have stable MAAS-assigned names _as well as_ user-assigned
>   names? In other words, do we need a name to refer to a node that
>   doesn't change between allocations of that node?
>
>   -> Previously I've considered this useful, but I'm not sure. For
>      troubleshooting and administration, it might be useful instead to
>      publish TXT records (or some other resource type) that gives more
>      details about the node.

One name is all you need. TXT records are not a bad idea but let's defer
till we really need it (nobody would consume that without a script or
utility and when they want to write that they can talk to us). More
importantly, whatever script would look at TXT records could also just
talk straight to MAAS.

> * For a floating VIP, what should a reverse lookup yield?
>
>   -> The name associated with the VIP (rather than, say, the FQDN of
>      each node currently servicing that VIP).

Overcomplicated. Just allow the user to specify the IP address
(validating it's in the range of the cluster) and do the lookups as you
currently do.

> * Should we allow multiple records with the same hostname, to support
>   round-robin? If so, we should limit to a single user; i.e. don't allow
>   round-robin between multiple users.
>
>   -> Not now, but we should implement the above with a hat-tip to doing
>      it later.

No. That can be handled entirely separately in DNS elsewhere.

>>  * Simple UI to configure available static IP range alongside the
>> dynamic ones (could be as simple as fitting it in to the existing
>> network for simplicity for now)
> We should avoid having configuration for the dynamic range if we can.
> No extra configuration! If we must have such a thing, it should be
> feature-flagged or at least in an "advanced" area.

I don't think it's particularly advanced. Please handle it as follows:
you have a range that the DHCP server can use for dynamic allocation,
and a range that MAAS expects to put nodes on. You can also attach IP
addresses to machines directly, both inside and out of the range MAAS
will use (but NOT overlapping the DHCP range) and you can provide some
non-MAAS host entries for DHCP too for things like routers and switches etc.

Make sense?

>>  * Remove job that writes host entries as soon as we know a machine's IP
>> (and its reverse when deleting the host)
> Because we'll be handing out addresses when a node is accepted we can
> write DNS records at that time. We still need to be able to change host
> names though.

You need to be able to rewrite the DNS and DHCP files every time
something changes.

>>
>> We need one other thing, which is sort-of implied above: an API for
>> obtaining extra static addresses. This is needed to allow a user or
>> agent (e.g. Juju) to obtain an externally routable address for a
>> container.
>>

Yes - please do associate those extra addresses with the node in MAAS so
it can be cleaned up when the node goes away, even if it has its own
virtual MAC address.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature