yahoo-eng-team team mailing list archive

[James Page <james.page@xxxxxxxxxx>]

Ubuntu SRU information

[Impact]
Use of Neutron internal DNS resolution for resolution of instances attached to the same project network is inconsistent due to use of configuration options for the actual hostname entries in the dnsmasq hosts file paired with the network 'dns_domain' attribute which is used to set the search path for the same dnsmasq instance.

[Test Case]
Deploy OpenStack with Neutron internal DNS support enabled
Configure neutron with a dns_domain of 'testcase.internal'
Set a dns_domain attribute on the project network ('designate.local')
Boot an instance attached to the network
DNS resolution within the host will be asymmetric in terms of the actual dns domain used.

  root@bionic-045546-2:~# host 192.168.21.222
  222.21.168.192.in-addr.arpa domain name pointer bionic-045546-2.testcase.internal.

  root@bionic-045546-2:~# host bionic-045546-2
  bionic-045546-2.designate.local has address 192.168.21.222

which should be

  root@bionic-045546-2:~# host bionic-045546-2
  bionic-045546-2.testcase.local has address 192.168.21.222


[Regression Potential] 
Minimal; the proposed fix actually reverts changes in Neutron which altered the behaviour of the internal DNS support in Neutron incorrectly.

[Other Info]
This change in behaviour has been discussed at the upstream Neutron irc meeting with consensus that the behaviour changes are incorrect and should be reverted.


** Also affects: cloud-archive
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/queens
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/train
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/rocky
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/stein
   Importance: Undecided
       Status: New

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

Title:
  dhcp agent configured with mismatching domain and host entries

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive queens series:
  New
Status in Ubuntu Cloud Archive rocky series:
  New
Status in Ubuntu Cloud Archive stein series:
  New
Status in Ubuntu Cloud Archive train series:
  New
Status in neutron:
  In Progress
Status in neutron package in Ubuntu:
  Fix Released
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:
  Fix Released

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@bionic-045546-2:~# host 192.168.21.222
    222.21.168.192.in-addr.arpa domain name pointer bionic-045546-2.jamespage.internal.
    root@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/cloud-archive/+bug/1826419/+subscriptions