maas-devel team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, Jul 19, 2012 at 6:14 PM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
>> 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.

we have to support classes node grouping yes, I don't recall a user
need that implies supporting RFC2317 reverse lookup: as long as we can
divide the rfc1918 space for node groups, DNS can do whatever is
desired. Some folk may run non-rfc1918 networks, but to date we're
expecting all deployments to be on private ranges (for MAAS and the
MAAS provision OS's).

To expand on this, there are two cases where we have to deal with a
partial octet:
 * External user splits: the user already has the same network range
they are giving to MAAS in use and MAAS is being given a slice of
that.
 * Within-MAAS splits: the user is carving out some of the ip range
MAAS has to be a node group with its own dedicated image server/TFTP
etc.

For Within-MAAS splits, there is no effect on the DNS zones: whatever
we have, whether octet split or rfc2317 based, can be preserved
unaltered when a nodegroup is carved out of the overall range(s) MAAS
has been given. (I can expand on that if needed, but it should be self
evident). All we need to do is replicate all the zones we manage to 1
or more MAAS DNS servers and we're done.

For external user splits, the external user DNS has to be configured
for RFC2317, as well as MAAS knowing the transformed DNS zone it
should use: see the example rvb gave, both the authoritative master
and MAAS have to cooperate.

So to the extent that we deal with external user splits, MAAS needs to
support RFC2317|not support classless allocation, but not because of
nodegroups.

We have two options here;
 - support RFC2317
 - don't support it and instead tell folk to allocate a full subnet,
or disable DNS management.

When we say 'we have to support classless networks', what specifically
are we talking about? What archetype won't have a full subnet in one
of the three RFC1918 ranges to give to MAAS [at the point they are
asking MAAS to take over DNS and DHCP] ?

We can avoid a lot of code if we don't need to do this, so I think its
important to figure out why we think we need to.

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

Totally! There is AIUI an option that says 'run DHCP or use existing',
and if use existing is set we just don't do anything about DHCP
settings. If we manage it, we can assign to the right pool on
enrollment.

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

With what I proposed, why do we have to?

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

Of course. I'm merely talking about what we should aim for.

-Rob