maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

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.

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.

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

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

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

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

>
>  * Add job to allocate and write host entry at node acquisition time,
> and return it in the API response

Now I don't really understand this point or the previous one :) What
gets returned in the API response?

>
>  * Add job to reclaim IP when a node is released.

This sounds like the above. I'm not sure what the changes are here.

>
> Anything else I think is gravy for now and not part of a *fix* for this
> bug; we can extend this change to do more later.

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.