maas 2 adds multiple DNS entries for nodes

Bug #1584569 reported by Brad Marshall
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MAAS
Won't Fix
Undecided
Unassigned

Bug Description

MAAS 2.0 appears to be generating two DNS entries for a node, one for just the bare hostname, and one with the network device its using prepended.

This means we end up with dns entries like:

$ host sleety-alfredo.maas
sleety-alfredo.maas has address 10.48.0.32

$ host 10.48.0.32
32.0.48.10.in-addr.arpa domain name pointer eth0.sleety-alfredo.maas.
32.0.48.10.in-addr.arpa domain name pointer sleety-alfredo.maas.

Many charms use the results from dns to find the hostname, in particularly charmhelpers.contrib.network.ip get_hostname essentially does a dns lookup, and then returns result.split('.')[0].

This means I'm seeing results like from rabbitmq-server charm:

  2016-05-23 02:38:24 INFO juju-log local nodename: eth0

This isn't working terribly well as you could imagine.

How do we tell MAAS 2.0 to not write out the network device related DNS entry? I've been investigating the docs, but I haven't found much. Having to change all the charms to deal with this will be quite a bit of work.

Revision history for this message
Brad Marshall (brad-marshall) wrote :

FWIW this will eventually work as it's returning the DNS in round robin, so the next retry of the hook should work fine. Regardless, this seems suboptimal to force it to have 2 hook runs to work.

Revision history for this message
Mike Pontillo (mpontillo) wrote :

I don't think we were aware that charms were relying on reverse DNS lookups to determine the hostname based on an IP address.

We were asked to do non-resolvable names for the interface-name-based PTR records, so that when a machine had multiple interfaces, it would show up nicely on a traceroute - but we did not add forward records for those entries, since it seemed like a bad idea for anything to rely on what could be an ephemeral name.

I think we should consider disabling the new feature which adds the interface-based names, at least for now.

Changed in maas:
assignee: nobody → LaMont Jones (lamont)
status: New → Triaged
importance: Undecided → Critical
milestone: none → 2.0.0
Revision history for this message
Blake Rouse (blake-rouse) wrote :

This is a new feature of MAAS 2.0. This is something that we will not change in MAAS for 2.0. We did not introduce this behavior in MAAS 1.9 and reserved it for MAAS 2.0. MAAS 2.0 has many breaking changes that make the produce overall better. This is one of them, it allows an administrator to convert an IP address to the exact interface on a deployed machine.

Changed in maas:
status: Triaged → Won't Fix
assignee: LaMont Jones (lamont) → nobody
importance: Critical → Medium
no longer affects: maas/1.9
Revision history for this message
Andres Rodriguez (andreserl) wrote :

This is actually a design change in MAAS to help address various of other issues in the field that were raised in the past. As a design change, MAAS won't fix this, but rather the charm will have to be updated to correctly parse hostnames from a machine when it has multiple DNS entries (which is a perfectly valid configuration).

Changed in maas:
importance: Medium → Undecided
Changed in maas:
milestone: 2.0.0 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.