yahoo-eng-team team mailing list archive

[Armando Migliaccio <1175211@xxxxxxxxxxxxxxxxxx>]

Sorry  I meant this one:

https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution

** Changed in: neutron
       Status: Confirmed => Fix Released

** Changed in: neutron
     Assignee: Dariusz Smigiel (smigiel-dariusz) => Miguel Lavalle (minsel)

** No longer affects: nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1175211

Title:
  quantum DNS name does not match VM hostname

Status in neutron:
  Fix Released

Bug description:
  Using Networking DHCP agent, cloud-init and Nova metadata, we're
  seeing a situation where the VM hostname does not match the DNS name.
  This causes things like 'sudo'  to complain and 'hostname -f' to fail
  on the VM, and represents a regression from existing nova-network
  behavior.

  An example of the problem and a potential solution are outlined below
  for comment.

  For example:

  $ nova list
  +--------------------------------------+---------+--------+-----------------------------------+
  | ID                                   | Name    | Status | Networks                          |
  +--------------------------------------+---------+--------+-----------------------------------+
  | 92a4075e-31a4-45e1-909d-f71ee4c55de4 | jvm44   | ACTIVE | jnet41=10.10.20.5|
  +--------------------------------------+---------+--------+-----------------------------------+

  On the VM:

  ubuntu@jvm44:~$ hostname
  jvm44

  ubuntu@jvm44:~$ hostname -f
  hostname: Temporary failure in name resolution

  ubuntu@jvm44:~$ sudo bash
  sudo: unable to resolve host jvm44
  root@jvm44:~#

  Changing the hostname to match DNS name fixes the problem:

  ubuntu@10-10-20-5:~$ hostname
  10-10-20-5

  ubuntu@10-10-20-5:~$ hostname -f
  10-10-20-5.openstacklocal

  ubuntu@10-10-20-5:~$ sudo bash
  root@10-10-20-5:~#

  The VM name in DNS is 10-10-20-5.openstacklocal. as seen here:

  root@jvm44:~# nslookup 10.10.20.5
  Server: 10.10.20.2
  Address: 10.10.20.2#53
  5.20.10.10.in-addr.arpa name = 10-10-20-5.openstacklocal.

  While DNSaaS may be the eventual answer to this problem, there may be
  a simpler fix for the case where DNSaaS is not available.

  A potential, minimally invasive fix for this might be:

  1) modify quantum/agent/linux/dhcp.py _output_hosts_file to set the
  DNS name from the port name (if port name is set and if it is a valid
  DNS name, otherwise set from fixed IP as currently done)

  2) modify nova to set the port name to match the VM name

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