Different tenants can assign the same hostname to different machines without an error

[Joseph Lorenzini]

nova version 2.15.0

My openstack deployment is relatively simple. It uses FlatDHCPManager and a single vlan. Multiple tenants exist and all are on the same vlan. Now consider the following situation:

1. tenant A and tenant B exist.
2. tenant A logs into horizon dashboard and launches an instance into vlan 192.168.50.X.
3. tenant A gives the instance a display name of "test". As a result, the DHCP server assigns the hostname "test" to the VM and an IP address of 192.168.50.2.
4. tenent B sometime later logs into the horizon dashboard.
5. tenant B has no visibility and consequently does not know that tenant A has a machine with a hostname of test in the 192.168.50 vlan.
6. tenant B launches an instance into vlan 192.168.50.X.
7. tenant B gives the instance a display name of "test". As a result, the DHCP server assigns the hostname "test" to the VM and an IP address of 192.168.50.3.

As a result, now when a nslookup is done on the hostname, two A records are returned instead of one. This situation would be far worse if each tenant launched multiple instances instead of just one. I don't know of a situation where anyone would want to automatically assign the same hostname to multiple IP addresses, especially when this behavior would be unknown to the tenants and would result in all kinds of bizarre networking behavior depending on the applications deployed in the vlan.

My expectation is that at a minimum if tenant B attempts to launch an instance with a hostname that already exists in the DHCP server's records, then that launch should fail and the tenant should be forced to change the display they tried to give the VM before a launch would be successful.

[Samuel de Medeiros Queiroz (samueldmq)]

Classes that inherit from NetworkManager, e.g. FlatDHCPManager, use the attribute instance_dns_manager to handle DNS service operations, such as creating new DNS entries.

This attribute is an instance of the class defined at CONF.instance_dns_manager, that is, by default, 'nova.network.noop_dns_driver.NoopDNSDriver'.

NoopDNSDriver, as suggested, does not do anything. However, other DNSDriver implementations like MiniDNS do. They verify if a DNS entry name is unique into the domain before adding the new DNS entry.

Changing this default configuration to 'nova.network.minidns.MiniDNS' at nova/network/floating_ips.py solved this issue:

    cfg.StrOpt('instance_dns_manager',
               default='nova.network.minidns.MiniDNS',
               help='Full class name for the DNS Manager for instance IPs'),

When trying to reproduce the bug after the modifications through Horizon, I got:

Error: Failed to launch instance "instance-name": Please try again later [Error: No valid host was found. ].

What do you think about this approach?

[Joseph Lorenzini (joseph-lorenzini)]

Overall, that looks good however could the exception be modified so that it tells the user the actual problem:

In other words, this:

[Error: No valid host was found. ].

Would be clearer if it was this instead:

[Error: An instance already exists with the hostname "instance name"].

[Samuel de Medeiros Queiroz (samueldmq)]

When using the MiniDNS driver, an exception of type exception.FloatingIpDNSExists is thrown.
This exception has the following message format: "The DNS entry %(name)s already exists in domain %(domain)s."

However, this message is changed at any point between Nova and Horizon; so I think this is out of the scope of this bug.
I think other bug should be created to make this message arrive correctly to the calling component, in this case, Horizon.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/94252

[Samuel de Medeiros Queiroz (samueldmq)]

In order to treat the wrong error that is being thrown, the following bug was created.
https://bugs.launchpad.net/nova/+bug/1321774

[Sean Dague (sdague)]

moving out of inprogress

[Sean Dague (sdague)]

Honestly, I don't think this is going to be fixed in the current scheme. Until we have a more solid dns management stack integrated this is going to be hard to really address.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Samuel de Medeiros Queiroz (<email address hidden>) on branch: master
Review: https://review.openstack.org/94252