maas-devel team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Thu, Jul 19, 2012 at 7:04 PM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
> On Thursday 19 July 2012 18:41:23 Robert Collins wrote:
>> 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.
>
> It's a question I've asked and I keep getting different answers.  Here's one
> from earlier :)
>
> <bigjools> lifeless: anyway the original question is not answered - do we care
> about the reverse zone being overly authoritative when there's a non-octet
> netmask boundary?
> <lifeless> yes, because otherwise it won't work for adjacent nodegroups
> <lifeless> you need to do rfc2317 if you have that sort of split.
>
> So, do we need to worry about this or not?!

So the literal question you asked, and the answer given are valid. I'm
suggesting ways we can avoid the complexity entirely by:
 - having the DNS zones we create never be overly authoratitive
 - unless the user explicitly imposes this on us for their choice of
top level networks (vs nodegroups)
 - and so only the code that adds top level networks would ever need
to do rfc2317 calculations.

> If we can avoid worrying about it then I'd be quite happy to move on at this
> point.  However, if it's on a network that's already split on non-octet
> boundaries I need to know what kind of problems are caused by the reverse zone
> being overly authoritative if we don't do rfc2317.

If you're on such a network, there are two dns zones, the real one,
with CNAMEs and the fake one.
If you don't do rfc2317 you have two zones that claim the same
knowledge, but don't cross-link each other, so:
 - if the client queries our DNS server for something outside that
actual knowledge, it will answer (and lie) ENOTFOUND
 - if the client queries the parent DNS server it will all work

But as the context for the proposed design was 'DNS server per
nodegroup', clearly all our clients would be querying the local DNS
server and thus ENOTFOUND for all adjacent nodegroup reverse lookups.

>> > 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?
>
> We don't if MAAS does all the allocation - I was just pointing out that we do
> if we use the lease file parsing method.

I don't understand where that method turns up. Here is my understanding;
 - mode A, MAAS controls DHCP. DHCP sets a tftp file etc, boot up to
enroll *via a temporary dynamic IP*; MAAS can allocate the permanent
IP at that time, next boot (for allocation) gets the real IP.
 - mode B, MAAS does not control DHCP. DHCP server is manually
configured for TFTP etc; boot up to enroll via a dynamic IP, and we
just accept the IP given.

Perhaps we should have a call, you me @ Raphael about this, tease it out?

-Rob