maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 22 May 2014 11:41:22 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.

We do but I am specifically talking about an additional range for static (vs 
existing dynamic)

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

Sounds good.

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

We get that for free already with the auto-generated zone.

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

If we have a use case for this that fits neatly into our vision/plans, then 
I'd say let's consider it, otherwise it's waste and let's forget it.

What use case did you have in mind?

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

We need to be careful here not to end up with the same problem we have with 
using CNAMEs as the primary hostname; that is, the CNAME -> IP -> A does not 
match and you get problems with things that need them to be the same 
(postgres, IIRC).

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

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

I don't see a problem with extra configuration here.  Let's have a sensible 
default that works OOTB (in a private range, say) across all clusters, and 
then we can make it configurable in case the admin wishes to make it routable 
without NAT.

Bear in mind all the existing deployments that would be affected by us 
changing the IP to a different network.  We can't make it not configurable.

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

I am assuming that we only hand out an address when a node is allocated.  See 
below for why.

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

The existing acquire() call returns the node's IP address.

> 
> >  * Add job to reclaim IP when a node is released.
> 
> This sounds like the above. I'm not sure what the changes are here.

Bearing in mind my assumption above, when the node is released the IP goes 
back to the pool of unused static addresses.

I actually think this is more flexible compared to assigning one to the node 
once it's accepted, as it gives you an opportunity to create VPNs on demand in 
the future.  We can't do that if the IP never changes once accepted.

Also, the user might want to assign one of their API-obtained user-based IPs.

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

This is exactly what I had in mind when I was talking about other stuff - we 
don't need that right now, we need to get this DHCP problem fixed without 
getting bogged down in side features.

Hopefully with this discussion we're identifying those side features so we do 
the fix in such a way that we don't make life harder for ourselves when 
implementing them.

Cheers
J