maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 19 July 2012 17:19:07 Robert Collins wrote:
> On Thu, Jul 19, 2012 at 4:53 PM, Julian Edwards
> 
> <julian.edwards@xxxxxxxxxxxxx> wrote:
> > Howdy
> > 
> > This isn't an approach that was considered when designing the DNS stuff
> > (forgive me if it was, I've been on parental leave for 2.5 weeks). 
> > However, bulk pre-allocation does solve a couple of problems and I like
> > it a lot.
> > 
> > The main problem is DNS Latency.  When updating the DNS based on randomly
> > DHCP-assigned IPs to hosts, there's a latency introduced with the
> > celerybeat polling approach that we had in mind.  If the zone files
> > remain relatively static (they'd be written only when the IP range for
> > the nodegroup changes), this simply ceases to be a problem at all.
> > 
> > I don't think this will be difficult to do - it just means we change the
> > event that triggers writing out the zone files (to when NodeGroup is
> > added/updated). Raphaël, we *do* still need to consider classless masks
> > though and use RFC2317.
> 
> Or use stock standard zones, and just replicate the full set to all
> the DNS servers, which will give you better response times and natural
> redundancy of service. I recommend this ;).

This is not in our control, it depends on the network topology of where it's 
being installed.  We have to support classless networks.

> > A second problem is one that came up just now on IRC when I was discussing
> > this with Rob: we must never allow the IP address of an allocated node to
> > change, because it will break things like Juju which assume it won't
> > change. When someone reboots an allocated node in a busy pool, it's
> > highly likely it will get a new IP when coming up again.
> > 
> > To solve this I just discussed a couple of options with jtv:
> >  1. Write out dhcp configs for static mappings of MAC to IP.
> >  2. Use a very long lease time.
> > 
> > We preferred the second option because the first means that we either have
> > to manually allocate IP addresses (thus defeating one of the points of a
> > DHCP server really), or we have to detect what the IP address was via the
> > leases file and write that mapping back to a static config, which
> > introduces a problematic latency.
> > 
> > If we use a long lease time, the only real problem is removing it when
> > decommissioning a node.  We should be able to do this easily with the
> > omshell utility which uses the OMAPI facility that ISC DHCP has.
> 
> What about assigning the IP during commissioning, so that you don't
> have to change the nodes address at any point - when its enrolling it
> gets dynamic address, when you enroll it into the system you assign a
> static address.

That's what I mean in the first part of point #1 above when I say we either 
assign it ourselves or figure out what the DHCP server gave it and make it 
stick.

We do have to bear in mind that people simply playing with MAAS (the seed 
cloud story) may not have control of a DHCP server on their network.

> FWIW, I've had much better results in previous (special case but
> similar bits) projects using static allocation: it avoids all the
> things that *can* go wrong with long leases (such as nodes choosing to
> relinquish the address and then getting a different one). I don't see
> that it would add any latency to the provisioning process either,
> though IMBW.

The latency is more to do with the fact that we have to react to the leases
file changing.

I suspect that in the future if all of this becomes really problematic then 
we'll just write our own DHCP server and run it as part of MAAS.  I think 
taking the simplistic approach right now and iterating improvements is the 
right way to go.

J