CNAME not added if PXE iface is different from first one in DB

[Andres Rodriguez]

So on maas 1.2 auto generated hostnames are no longer MAC based. Both when adding a node *without* specifying a hostname through maas-enlist or the WebUI, the hostname generated is in the form of:

nmewt.<domain>

where nmewt is a random generated name.

What is even worse, is that no CNAME gets created for such hostname, causing that sthings such as juju, can't address to these nodes.

If we change the hostname to spomething not random... the new hostname does NOT get added as a CNAME on DNS.

However, DNS works by addressing to the hosts in the way of 'X-Y-Z-A.domian' being x.y.z.a the ip.

Some more info (which is additional/complementary to the issues we are seeing):

=== Tue, 05 Feb 2013 22:34:55 +0000: successfully enlisted to 'http://15.126.38.
10/MAAS/api/1.0/nodes/' with hostname '15-126-38-49'
{
    "status": 0,
    "macaddress_set": [
        {
            "mac_address": "X"
        },
        {
            "mac_address": "Y1"
        },
        {
            "mac_address": "Z
        }
    ],
    "netboot": true,
    "hostname": "qgre8.domain",
    "power_type": "ipmi",
    "system_id": "node-3a8865ae-6fe4-11e2-a412-78e7d1248dfd",

So it seems that if it tries to register itself with a hostname equal to a DNS name already in MAAS based on the IP, it will also generate a a random hostname.

Note that the random hostname is also generated if NO hostname is sent during enlistment.

==================================
this appears in celery.log don't know if related.

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/celery/execute/trace.py", line 47, in trace
    return cls(states.SUCCESS, retval=fun(*args, **kwargs))
  File "/usr/lib/python2.7/dist-packages/celery/app/task/__init__.py", line 247, in __call__
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/celery/app/__init__.py", line 175, in run
    return fun(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/provisioningserver/tasks.py", line 300, in remove_dhcp_host_map
    omshell.remove(ip_address)
  File "/usr/lib/python2.7/dist-packages/provisioningserver/omshell.py", line 192, in remove
    raise CalledProcessError(returncode, "omshell", output)

[Julian Edwards (julian-edwards)]

This ought to work, I personally tested this (and it was tested in the QA lab). Can you look at the region celery log for errors.

[Julian Edwards (julian-edwards)]

(the region worker is responsible for writing DNS entries)

[Scott Moser (smoser)]

I've tested locally and not been able to reproduce this.
http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-precise-1.2.txt is what I did inside a new ubuntu instance.

After registering a node, I then see:
$ tail -n 4 /etc/bind/maas/zone.master
192-168-77-254 IN A 192.168.77.254
192-168-77-255 IN A 192.168.77.255
9cxp7 IN CNAME 192-168-77-6
xrqxm IN CNAME 192-168-77-5

$ host 192-168-77-6.master localhost | tail -n 1
192-168-77-6.master has address 192.168.77.6
$ host 9cxp7.master localhost | tail -n 2
9cxp7.master is an alias for 192-168-77-6.master.
192-168-77-6.master has address 192.168.77.6

Just to be clear, though:
$ host 9cxp7 localhost | tail -n 1
Host 9cxp7 not found: 3(NXDOMAIN)

Ie, I wasn't searching '.master' by default.

Searching further on that theme, I booted a new instance and dhcp'd from maas, and my /etc/resolv.conf contains:
   | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
   | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
   | nameserver 10.55.60.184

sorely lacking there is 'search' entries for 'master'.
Then, checking /etc/maas/dhcpd.conf there is no 'domainname' or 'domain-search' entries.

It seems that we probably need one of those 2 things.

[Julian Edwards (julian-edwards)]

Well Andres said that no CNAME was generated, so let's see what logs he comes up with. In any case, yes, you need a "search" config at the least.

[Andres Rodriguez (andreserl)]

Ok so thanks to Julian, we found what the issue was. Currently, we were using eth2 for PXE. however, when it registers the node to maas it registers all the network interfaces for the node.

However, MAAS does the CNAME aggregation/mapping based on the first interface registered (this case eth1 - get_hostname_ip_mapping). The work around is to only make maas-enlsit register the interface where it PXE booted from, however, this is just a work around.

Thanks for all the help!

[Julian Edwards (julian-edwards)]

The problem exists in get_hostname_ip_mapping() in dhcplease.py. The SQL statement used restricts the matching MAC address to the first one it finds in the database for the node. JTV says he can fix this, so I'll assign it his way.

[Jeroen T. Vermeulen (jtv)]

Here's my impression and suggested solution: http://paste.ubuntu.com/1615145/