| 2013-02-05 21:55:48 |
Andres Rodriguez |
bug |
|
|
added bug |
| 2013-02-05 21:56:00 |
Andres Rodriguez |
maas: importance |
Undecided |
Critical |
|
| 2013-02-05 22:00:47 |
Andres Rodriguez |
description |
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>
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. |
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>
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. |
|
| 2013-02-05 22:02:04 |
Joshua R. Poulson |
bug |
|
|
added subscriber Joshua R. Poulson |
| 2013-02-05 22:09:13 |
Andres Rodriguez |
description |
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>
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. |
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. |
|
| 2013-02-05 22:38:19 |
Andres Rodriguez |
description |
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. |
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. |
|
| 2013-02-05 22:44:29 |
Andres Rodriguez |
description |
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. |
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) |
|
| 2013-02-06 00:32:20 |
Julian Edwards |
maas: status |
New |
Incomplete |
|
| 2013-02-06 05:48:48 |
Andres Rodriguez |
summary |
MAAS 1.2 no longer auto generates a MAC based hostname |
MAAS doesn't add CNAME if PXE iface is different from first one in DB |
|
| 2013-02-06 05:48:59 |
Andres Rodriguez |
summary |
MAAS doesn't add CNAME if PXE iface is different from first one in DB |
CNAME not added if PXE iface is different from first one in DB |
|
| 2013-02-06 06:16:04 |
Julian Edwards |
maas: status |
Incomplete |
Triaged |
|
| 2013-02-06 06:16:14 |
Julian Edwards |
maas: assignee |
|
Jeroen T. Vermeulen (jtv) |
|
| 2013-02-06 06:17:00 |
Julian Edwards |
nominated for series |
|
maas/1.2 |
|
| 2013-02-06 06:17:00 |
Julian Edwards |
bug task added |
|
maas/1.2 |
|
| 2013-02-06 06:17:00 |
Julian Edwards |
nominated for series |
|
maas/trunk |
|
| 2013-02-06 06:17:00 |
Julian Edwards |
bug task added |
|
maas/trunk |
|
| 2013-02-06 06:17:36 |
Julian Edwards |
maas/1.2: status |
New |
Triaged |
|
| 2013-02-06 06:17:37 |
Julian Edwards |
maas/1.2: importance |
Undecided |
Critical |
|
| 2013-02-06 06:17:45 |
Julian Edwards |
maas/1.2: assignee |
|
Jeroen T. Vermeulen (jtv) |
|
| 2013-02-06 06:17:47 |
Julian Edwards |
maas/1.2: milestone |
|
12.10-stabilization |
|
| 2013-02-06 10:45:12 |
Launchpad Janitor |
branch linked |
|
lp:~jtv/maas/bug-1116700 |
|
| 2013-02-07 04:17:51 |
MAAS Lander |
maas/trunk: status |
Triaged |
Fix Committed |
|
| 2013-02-07 06:28:43 |
Launchpad Janitor |
branch linked |
|
lp:~jtv/maas/1.2-bug-1116700 |
|
| 2013-02-07 07:16:52 |
MAAS Lander |
maas/1.2: status |
Triaged |
Fix Committed |
|
| 2013-02-11 00:49:09 |
Julian Edwards |
maas/trunk: status |
Fix Committed |
Fix Released |
|
| 2013-06-06 05:49:46 |
Julian Edwards |
maas/1.2: status |
Fix Committed |
Fix Released |
|
