← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1283538] [NEW] Different tenants can assign the same hostname to different machines without an error

 

Public bug reported:

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.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1283538

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

Status in OpenStack Compute (Nova):
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1283538/+subscriptions


Follow ups

References