On Thu, Jul 19, 2012 at 4:53 PM, Julian Edwards <[email protected]> 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 ;). > 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. 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. -Rob -- Mailing list: https://launchpad.net/~maas-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~maas-devel More help : https://help.launchpad.net/ListHelp
