[Bug 1826419] Re: dhcp agent configured with mismatching domain and host entries

[James Page]

As discussed at the Neutron L3 meeting last week, it was agreed that the
current behaviour is not compliant with either of the two original specs
related to Internal DNS and external DNS integration and that the
behaviour change would be reverts in master and back to
stable/{queens,rocky,stein} branches.

I have the master branch up for review with an associated revert in
neutron-tempest-plugin and have stable branch updates prepared but not
yet up for review (just waiting for master branch to complete testing
and I'll put them all up).

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1826419

Title:
  dhcp agent configured with mismatching domain and host entries

Status in neutron:
  In Progress
Status in neutron package in Ubuntu:
  Triaged
Status in neutron source package in Bionic:
  Triaged
Status in neutron source package in Cosmic:
  Triaged
Status in neutron source package in Disco:
  Triaged
Status in neutron source package in Eoan:
  Triaged

Bug description:
  Related bug 1774710 and bug 1580588

  The neutron-dhcp-agent in OpenStack >= Queens makes use of the
  dns_domain value set on a network to configure the '--domain'
  parameter of the dnsmasq instance that supports it;  at the same time,
  neutron makes use of CONF.dns_domain when creating dns_assignments for
  ports - this results in a hosts file for the dnsmasq instance which
  uses CONF.dns_domain and a --domain parameter of network.dns_domain
  which do not match.

  This results in a search path on instances booted attached to the
  network which is inconsistent with the internal DNS entries that
  dnsmasq responds with:

    root at bionic-045546-2:~# host 192.168.21.222
    222.21.168.192.in-addr.arpa domain name pointer bionic-045546-2.jamespage.internal.
    root at bionic-045546-2:~# host bionic-045546-2
    bionic-045546-2.designate.local has address 192.168.21.222

  In the above example:

    CONF.dns_domain = jamespage.internal.
    network.dns_domain = designate.local.

  Based on previous discussion in bug 1580588 I think that the
  dns_domain value for a network was intented for use for external DNS
  integration such as that provided by Designate.

  The changed made under commit:

    https://opendev.org/openstack/neutron/commit/137a6d61053

  appear to break this assumption, producing somewhat inconsistent
  behaviour in the dnsmasq instance for the network.

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