← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #64884

[Bug 1698010] [NEW] dhcp-domain is deprecated, but required for correct FQDN behavior

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

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.

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

Title:
  dhcp-domain is deprecated, but required for correct FQDN behavior

Status in OpenStack Compute (nova):
  New

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

Follow ups

  Thread Previous • Date Previous • • Thread Next