← Back to team overview

maas-devel team mailing list archive

Re: Strategy regarding DNS and static DHCP leases

 

I think this reflects clearly the content of our call earlier. Just a few remarks about the problems this doesn't solve and the challenges it poses.

  * Write the entire zone file when adding/updating node groups by generating
hostnames based on IP (like ec2 does).

That will simplify DNS configuration writing a lot. All the code I've written so far to write DNS configuration files will still be used, it will simply be hooked to a nodegroups rather than to a nodegroups *and* nodes.

Note that this doesn't solve the fact that MAAS' DNS server will have to be authoritative for the whole superset classfull subnet when registering classless subnets. e.g.: if we register 206.126.7.64/27, the DNS server will be authoritative for the corresponding classful network (i.e. the class C network: 206.126.7.0/24).

The "external user splits" problem Robert mentioned in the previous discussion about DNS is still there. Unless there is something I don't know about DNS configuration I think that's a problem we can't really solve anyway because BIND needs to have the zones it manages defined as classful subnets.

  * The existing lease file parser will still be necessary so that it can tell
[...]

   * The hostname on the node will become read-only.

That is obviously the price we have to pay for the simplification and that will require some changes to many areas of the code (API, UI, model code). But that definitely seems doable and going in the right direction.

Note that a node will be without a hostname until an IP has been allocated for that node. We will need a way to display (in the UI) a name for that node even before a proper hostname is set. I suggest we revisit our decision not to display the (auto-generated) node's system_id and use that in the UI until a hostname is set.



Follow ups

References