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

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.