← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1698010] Re: neutron-based instances should not use the nova-network 'dhcp_domain' option

 

Reviewed:  https://review.openstack.org/480616
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=886b0a5d748ae1deda3a039734f831d7c0cf0476
Submitter: Zuul
Branch:    master

commit 886b0a5d748ae1deda3a039734f831d7c0cf0476
Author: Stephen Finucane <sfinucan@xxxxxxxxxx>
Date:   Wed Jul 5 15:29:17 2017 +0100

    conf: Undeprecate and move the 'dhcp_domain' option
    
    The metadata service makes use of the deprecated '[DEFAULT] dhcp_domain'
    option when providing a hostname to the instance. This is used by
    cloud-init to configure the hostname in the instance. This use was not
    captured when the option was initially deprecated. This option is now
    undeprecated and moved to the '[api]' group to ensure it won't be
    removed alongside the other nova-network options.
    
    Change-Id: I3940ebd1888d8019716e7d4eb6d4a413a37b9b78
    Closes-Bug: #1698010


** Changed in: nova
       Status: In Progress => Fix Released

-- 
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/1698010

Title:
  neutron-based instances should not use the nova-network 'dhcp_domain'
  option

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  There seems to be an issue with how domains get assigned when booting
  instances.  My understanding is that with neutron, the neutron
  dns_domain option should be what determines the resulting domain name
  of the instances.  However, when creating instances with the following
  configuration:

  (undercloud) [centos@undercloud-test ~]$ sudo grep dns_domain /etc/neutron/neutron.conf 
  #dns_domain = openstacklocal
  dns_domain=nemebean.com
  (undercloud) [centos@undercloud-test ~]$ sudo grep dhcp_domain /etc/nova/nova.conf 
  #dhcp_domain=novalocal
  dhcp_domain=

  I get the following in the instance:

  [heat-admin@overcloud-controller-0 ~]$ sudo hostnamectl
     Static hostname: overcloud-controller-0.localdomain

  It looks like this is being done by cloud-init:

  Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] cc_set_hostname.py[DEBUG]: Setting the hostname to overcloud-controller-0.localdomain (overcloud-controller-0)
  Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] util.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'overcloud-controller-0.localdomain'] with allowed return codes [0] (shell=False, capture=True)

  So cloud-init is likely getting the host and domain name from Nova
  metadata, even though Neutron is being used to manage networking.

  If I also set dhcp_domain as follows:

  (undercloud) [centos@undercloud-test ~]$ sudo grep dhcp_domain /etc/nova/nova.conf 
  #dhcp_domain=novalocal
  dhcp_domain=nemebean.com

  Then I get the expected results:

  [heat-admin@overcloud-controller-0 ~]$ sudo hostnamectl
     Static hostname: overcloud-controller-0.nemebean.com

  These are obviously tripleo overcloud instances being deployed via
  Ironic.  I'm using some recent RDO packages:

  $ sudo rpm -qa | grep nova
  openstack-nova-conductor-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  python-nova-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  puppet-nova-11.1.0-0.20170605232112.27baec7.el7.centos.noarch
  openstack-nova-common-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  python2-novaclient-8.0.0-0.20170517113627.e1b9e76.el7.centos.noarch
  openstack-nova-placement-api-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  openstack-nova-api-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  openstack-nova-scheduler-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
  openstack-nova-compute-16.0.0-0.20170521033533.99bd334.el7.centos.noarch

  99bd334 is the short sha of the commit the packages were built against

  $ sudo rpm -qa | grep neutron
  python-neutron-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
  openstack-neutron-ml2-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
  python2-neutronclient-6.2.0-0.20170418195232.06d3dfd.el7.centos.noarch
  openstack-neutron-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
  openstack-neutron-openvswitch-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
  puppet-neutron-11.1.0-0.20170601210926.888c480.el7.centos.noarch
  python-neutron-lib-1.6.0-0.20170503061451.449f079.el7.centos.noarch
  openstack-neutron-common-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch

  This is not ideal in any case, but it's particularly concerning since
  according to the opt docs dhcp_domain is deprecated.

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


References