maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 19 July 2012 14:19:18 Robert Collins wrote:
> On Thu, Jul 19, 2012 at 3:28 AM, Raphaël Badin
> 
> <raphael.badin@xxxxxxxxxxxxx> wrote:
> > Hi List (and Rob),
> 
> ...
> 
> I'd like to ask a background question, but first to ack that I have
> the full picture:
>  - we are trying to update both forward and backward dns zones
>  - we are not using DHCP's inbuild facility for that for a good reason
>  - and we're running into reverse lookup mapping constraints that
> caused rfc2317 to be written.
> 
> So my background question is - why don't we what EC2 do and bulk setup
> DNS in both directions for the entire range?
> 
> Here is an example ec2 address: ec2-204-236-202-134.compute-1.amazonaws.com
> and reverse: host 204.236.202.134
> 134.202.236.204.in-addr.arpa domain name pointer
> ec2-204-236-202-134.compute-1.amazonaws.com.
> 
> So, you could imagine setting up N DNS servers all with identical
> configuration, and DHCP has no effect on DNS at all. N would be
> however many we want for scaling and load - it could be that N ==
> nodegroups.
> 
> -Rob

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.

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.

J