DNS failure when using MAAS DNS and multiple interfaces
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Cloud Controller Charm |
Expired
|
Undecided
|
Unassigned | ||
OpenStack Nova Compute Charm |
Expired
|
Undecided
|
Unassigned |
Bug Description
When using MAAS DNS and multiple interfaces, MAAS registers different hostnames for each interface.
So on a machine (hostname: node01 with multiple VLANs eg,
eth0: 10.10.0.5/24 (vid: untagged)
eth0.2: 10.20.0.5/24 (vid: 2)
you get 2 DNS entries
- node01.maas => 10.10.0.5
- eth0.2.node01.maas => 10.20.0.5
when using "spaces" so that you're potentially using both interfaces
the following error occurs during "live migration" and more specifically the 'cloud-
/var/log/
that results from the following code in hooks/nova-
short = private_
short = hn.split('.')[0] (1094)
If you need more information/logs, let me know and I'm happy to provide it
This pattern also occurs in a wide range of openstack charms due to its inclusion in the charmhelpers code base, including
charm-ceph-mon
charm-ceph-osd
charm-ceph-radosgw
charm-cinder
charm-glance
charm-keystone
charm-neutron-api
charm-neutron-
charm-neutron-
charm-nova-
charm-nova-compute
charm-openstack
charm-percona-
charm-rabbitmq-
specifically:
- charmhelpers/
- charmhelpers/
Unsure of the consequences of this, as so far I've only encountered an error with nova cloud controller
Possible fix would be to replace
fqdn.split('.')[0] with '.'.join(
but I can't convince myself this is the right approach either as it doesn't seem it would play nicely with complex sub domains. Why not use fqdns instead of short hostnames when you have them.
description: | updated |
Scoping bug back to potential impact area; most charms carry a copy of charmhelpers but they won't be impacted by this issue.