dhcp agent configured with mismatching domain and host entries

[James Page]

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.

[Boden R (boden)]

Is this simple enough to reproduce with devstack?
If so can you please share the steps to do so?

Thanks

[James Page (james-page)]

Fairly; I was able to reproduce the mismatch even without designate; specifically:

/etc/neutron/plugins/ml2/ml2_conf.ini

 [ml2]
 extension_drivers = port_security,dns_domain_ports

/etc/neutron/neutron.conf

 [DEFAULT]
 dns_domain = jamespage.example.

I then updated the dns_domain on the private network:

 openstack network set private --dns-domain designate.example.

and booted a couple of instances:

$ dnsmasq --no-hosts --pid-file=/opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/pid --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/host --addn-hosts=/opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/addn_hosts --dhcp-optsfile=/opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/opts --dhcp-leasefile=/opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/leases --dhcp-match=set:ipxe,175 --dhcp-userclass=set:ipxe6,iPXE --local-service --bind-interfaces --dhcp-range=set:tag1,10.0.0.0,static,255.255.255.192,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=64 --conf-file= --domain=designate.example.

$ cat /opt/stack/data/neutron/dhcp/e2637497-2ed8-4a08-9cca-9b2cd86accd1/host
fa:16:3e:9f:cf:f8,host-10-0-0-1.jamespage.example.,10.0.0.1
fa:16:3e:c3:0e:f7,host-10-0-0-2.jamespage.example.,10.0.0.2
fa:16:3e:4d:fc:2f,testserver-1.jamespage.example.,10.0.0.10
fa:16:3e:41:f8:61,testserver-2.jamespage.example.,10.0.0.32

you can clearly see that the entries in the host file are based on the configured jamespage.example. but that the domain is set to designate.example. as configured on the network.

This generates the forward/reverse DNS lookup mismatch from an instance perspective.

The dns_assignment of one of the servers ports looks like:

| dns_assignment | fqdn='testserver-1.jamespage.example.', hostname='testserver-1', ip_address='10.0.0.10' |

this is used to populate the dnsmasq host file.

[Boden R (boden)]

Hoping someone with more history on the dns_domain/domain can chime in on this one.
It's not clear to me if this is a bug or potentially a new RFE to change behavior.

[James Page (james-page)]

I think it would be good to get a clear consensus on the intent in neutron with regards to use of dns attributes on networks and dns in configuration; behaviour has changed in a somewhat confusing way as of >= Queens for some use cases and resolution of this bug really depends on what neutron should be doing - which might be right today, but it might also be conceptually wrong.

The only original intent I could track down was in IRC:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-05-19-22.01.log.html#l-251

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/657806

[James Page (james-page)]

@minsel

Apologies - I was not expecting my review to re-assign the bug to me.

[Jorge Niedbalski (niedbalski)]

I am able to reproduce the bug 1) Forward and reverse resolution is not honoring the network defined dns-domain. -expressed on my previous comment without even having designate enabled on my setup.

Deploying this bundle: http://paste.ubuntu.com/p/FZff5NqfvN/ , with the following neutron config options, please
note that a global.neutron. domain has been configured for neutron.

    options:
      dns-domain: global.neutron.
      enable-ml2-dns: true
      enable-ml2-port-security: true
      flat-network-providers: physnet1
      neutron-security-groups: true
      reverse-dns-lookup: true

Then associating a specific domain (local.neutron) to the private network:

$ neutron net-update --dns-domain local.neutron. private

ubuntu@niedbalski-bastion:~/stsstack-bundles/openstack$ openstack network show private | grep dns_domain
| dns_domain | local.neutron. |

After this step, I launched 3 instances that are associated to this private network.Then if I look into
the --domain attribute of the dnsmasq instance I can see that the configured domain remains as the dns-domain
set for the network.

verifying the --dns-domain option used on the instances network namespace.
root@juju-2e7dc7-1826419-5:/home/ubuntu# ip netns exec qrouter-c5a67f6a-3a15-4dcd-923d-c5c457beddff bash
root@juju-2e7dc7-1826419-5:/home/ubuntu# ps aux|grep dns|grep domain
nobody 491 0.0 0.0 53328 2888 ? S 17:00 0:00 dnsmasq --no-hosts --no-resolv --except-interface=lo --[...]
87/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=ns-75130a43-55 --dhcp-range=set:tag0,192.168.21.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1458 --dhcp-lease-max=256 --conf-file=/etc/neutron/dnsmasq.conf --domain=local.neutron.

However, the dhcp host file generated from the dns-assignments are pointing to the global
domain set in neutron-api.

root@juju-2e7dc7-1826419-5:/home/ubuntu# more /var/lib/neutron/dhcp/77902f51-2ac8-4ef1-97d1-962dd745ba87/host

fa:16:3e:d0:80:35,host-192-168-21-1.global.neutron.,192.168.21.1
fa:16:3e:f0:e2:a5,host-192-168-21-2.global.neutron.,192.168.21.2
fa:16:3e:1d:25:6d,cirros-170754-1.global.neutron.,192.168.21.4
fa:16:3e:39:12:a2,cirros-170754-2.global.neutron.,192.168.21.5
fa:16:3e:5b:cd:48,cirros-170754-3.global.neutron.,192.168.21.16

Then if I look at any of the port's dns-assignment they're also pointing to the global.neutron. domain,
not the one defined for the network

ubuntu@niedbalski-bastion:~/stsstack-bundles/openstack$ neutron port-show 75130a43-558e-4b17-90b8-45dc853fbaf7 | grep dns
| dns_assignment | {"hostname": "host-192-168-21-2", "ip_address": "192.168.21.2", "fqdn": "host-192-168-21-2.global.neutron."} |

This port assignment explains the mismatch in the dnsmasq resolution, because this is used for generating
the hosts file used by dnsmasq.

In my opinion rather than reverting this patch, the way to fix this is to adjust the https://github.com/openstack/neutron/blob/c21d922abd1208a72fe64d404a8eab93e0c56870/neutron/plugins/ml2/extensions/dns_integration.py#L287
dns_assignment update to use the network provided dns_name instead of the global configuration.

[Jorge Niedbalski (niedbalski)]

@minsel, Miguel Lavalle

Can you check my latest comment? What's your intention for going forward fixing
the explained behavior? Are you actively working on a draft/patch for fixing this? If so, do yo mind to explain me the approach you are following here?

Thanks

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/662713

[James Page (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).

[James Page (james-page)]

Log from IRC meeting for future followers:

  http://eavesdrop.openstack.org/meetings/neutron_l3/2019/neutron_l3.2019-05-29-14.00.log.html

[Launchpad Janitor (janitor)]

This bug was fixed in the package neutron - 2:14.0.0-0ubuntu2

---------------
neutron (2:14.0.0-0ubuntu2) eoan; urgency=medium

  * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes
    to internal DNS behaviour (LP: #1826419).

 -- James Page <email address hidden> Mon, 03 Jun 2019 10:33:42 +0100

[James Page (james-page)]

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.

[Brian Murray (brian-murray)]

Hello James, or anyone else affected,

Accepted neutron into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/neutron/2:14.0.0-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello James, or anyone else affected,

Accepted neutron into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/neutron/2:13.0.2-0ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello James, or anyone else affected,

Accepted neutron into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/neutron/2:12.0.6-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[James Page (james-page)]

disco/proposed:

ubuntu@xenial-074242-1:~$ host xenial-074242-2
xenial-074242-2.openstack.example has address 192.168.21.181

ubuntu@xenial-074242-1:~$ host 192.168.21.181
181.21.168.192.in-addr.arpa domain name pointer xenial-074242-2.openstack.example.

Forward and reverse lookups are consistent and are using the neutron configuration option rather than the dns_domain set on the network:

$ openstack network show private -f value -c dns_domain
jamespage.external.

[James Page (james-page)]

cosmic/proposed:

ubuntu@xenial-103848-1:~$ host xenial-103848-2
xenial-103848-2.openstack.example has address 192.168.21.6

ubuntu@xenial-103848-1:~$ host 192.168.21.6
6.21.168.192.in-addr.arpa domain name pointer xenial-103848-2.openstack.example.

Forward and reverse lookups are consistent and are using the neutron configuration option rather than the dns_domain set on the network:

$ openstack network show private -f value -c dns_domain
jamespage.external.

[James Page (james-page)]

bionic/proposed:

ubuntu@xenial-113550-1:~$ host xenial-113550-2
xenial-113550-2.openstack.example has address 192.168.21.6

ubuntu@xenial-113550-1:~$ host 192.168.21.6
6.21.168.192.in-addr.arpa domain name pointer xenial-113550-2.openstack.example.

Forward and reverse lookups are consistent and are using the neutron configuration option rather than the dns_domain set on the network:

$ openstack network show private -f value -c dns_domain
jamespage.external.

[James Page (james-page)]

Hello James, or anyone else affected,

Accepted neutron into queens-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:queens-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-queens-needed to verification-queens-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-queens-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[James Page (james-page)]

Hello James, or anyone else affected,

Accepted neutron into rocky-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:rocky-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-rocky-needed to verification-rocky-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-rocky-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[James Page (james-page)]

Hello James, or anyone else affected,

Accepted neutron into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[James Page (james-page)]

bionic-stein/proposed

ubuntu@xenial-142455-1:~$ host xenial-142455-2
xenial-142455-2.openstack.example has address 192.168.21.108

ubuntu@xenial-142455-1:~$ host 192.168.21.108
108.21.168.192.in-addr.arpa domain name pointer xenial-142455-2.openstack.example.

[James Page (james-page)]

bionic-rocky/proposed

xenial-090914-1:~$ host xenial-090914-2
xenial-090914-2.openstack.example has address 192.168.21.27

ubuntu@xenial-090914-1:~$ host 192.168.21.27
27.21.168.192.in-addr.arpa domain name pointer xenial-090914-2.openstack.example.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/664238

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/662713
Committed: https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=e142c0b6e9d935ec37bdcab4efbca7c2ca9b150e
Submitter: Zuul
Branch: master

commit e142c0b6e9d935ec37bdcab4efbca7c2ca9b150e
Author: James Page <email address hidden>
Date: Mon Jun 3 09:23:40 2019 +0100

    Ensure DNS configuration from conf

    For internal DNS the DNS configuration including the search
    path should be derived from configuration rather than from
    the dns_domain attribute of the network, which is used for
    external DNS integration.

    Update test to ensure that configuration based dns domain
    is present in the server search path and is used to validate
    resolution of the hostname of the server.

    This commit also temporaily skips the internal DNS test whilst
    the associated Neutron reviews are landed; it will be re-enabled
    afterwards.

    Change-Id: I145144c042b100f7e12a02a8ac7e0fbbe41e984d
    Related-Bug: 1826419
    Required-By: I5ff03b5ad8af432a9f7919ef953d7d8c434b93bd

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/657806
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8f5020120e4fb6789dcf8cda92343fde55f14aee
Submitter: Zuul
Branch: master

commit 8f5020120e4fb6789dcf8cda92343fde55f14aee
Author: James Page <email address hidden>
Date: Sat May 4 09:21:28 2019 -0600

    Revert "Pass network's dns_domain to dnsmasq conf"

    The dns_domain attribute of a network is intended for use
    by neutron when creating DNS records in an external DNS
    system such as Designate.

    By using the networks dns_domain, the configured search
    path on booted instances mismatches with the generated
    dns assignments for instance ports in the hosts file
    for dnsmasq which creates a mismatched forward/reverse
    lookup behaviour.

    This reverts commit 137a6d61053fb1cfb9a0a583b5a5c0f6253c75e6
    and commit 7fdd6adc7acf99e74fbe1c12606f8c867ae134ae.

    Closes-Bug: 1826419
    Depends-On: I145144c042b100f7e12a02a8ac7e0fbbe41e984d
    Change-Id: I5ff03b5ad8af432a9f7919ef953d7d8c434b93bd

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/663293
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8c7c26c5bdb87ab7c30b5b50ec925c49ac4c01d4
Submitter: Zuul
Branch: stable/queens

commit 8c7c26c5bdb87ab7c30b5b50ec925c49ac4c01d4
Author: James Page <email address hidden>
Date: Mon Jun 3 09:38:16 2019 +0100

    Revert "Pass network's dns_domain to dnsmasq conf"

    The dns_domain attribute of a network is intended for use
    by neutron when creating DNS records in an external DNS
    system such as Designate.

    By using the networks dns_domain, the configured search
    path on booted instances mismatches with the generated
    dns assignments for instance ports in the hosts file
    for dnsmasq which creates a mismatched forward/reverse
    lookup behaviour.

    This reverts commit 28b90f6c14659500694f321eedbf313d83a2ae9c.

    Change-Id: I26b5e8c35233718d97e58cfd5735c62d1684b4b0
    Closes-Bug: 1826419
    Depends-On: I145144c042b100f7e12a02a8ac7e0fbbe41e984d

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/663294
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c80598dd587e8462a860ab46f1baf3a5a8626f07
Submitter: Zuul
Branch: stable/rocky

commit c80598dd587e8462a860ab46f1baf3a5a8626f07
Author: James Page <email address hidden>
Date: Mon Jun 3 09:39:58 2019 +0100

    Revert "Pass network's dns_domain to dnsmasq conf"

    The dns_domain attribute of a network is intended for use
    by neutron when creating DNS records in an external DNS
    system such as Designate.

    By using the networks dns_domain, the configured search
    path on booted instances mismatches with the generated
    dns assignments for instance ports in the hosts file
    for dnsmasq which creates a mismatched forward/reverse
    lookup behaviour.

    This reverts commit b7796f6c91b74440780056712060da5da69e583f.
    and commit 137a6d61053fb1cfb9a0a583b5a5c0f6253c75e6.

    Change-Id: Icf253a2d969828f3bd3c629c3765e15e9769be28
    Closes-Bug: 1826419
    Depends-On: I145144c042b100f7e12a02a8ac7e0fbbe41e984d

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/664578

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/664584

[OpenStack Infra (hudson-openstack)]

Change abandoned by James Page (<email address hidden>) on branch: stable/stein
Review: https://review.opendev.org/663295

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for neutron has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package neutron - 2:13.0.2-0ubuntu3.3

---------------
neutron (2:13.0.2-0ubuntu3.3) cosmic; urgency=medium

  * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes to
    internal DNS behaviour (LP: #1826419).

 -- James Page <email address hidden> Tue, 04 Jun 2019 09:40:48 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package neutron - 2:12.0.6-0ubuntu1

---------------
neutron (2:12.0.6-0ubuntu1) bionic; urgency=medium

  [ Sahid Orentino Ferdjaoui ]
  * New stable point release for OpenStack Queens (LP: #1830341).
  * d/p/set-initial-ha-router-state-in-neutron-keepalived-st.patch,
    d/p/fix-KeyError-in-OVS-firewall.patch,
    d/p/metadata-use-requests-for-comms-with-nova-api.patch,
    d/p/Spawn-metadata-proxy-on-dvr-ha-standby-routers.patch,
    d/p/bug1823038.patch: Dropped. Fixed in upstream release.

  [ James Page ]
  * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes to
    internal DNS behaviour (LP: #1826419).

 -- Sahid Orentino Ferdjaoui <email address hidden> Fri, 24 May 2019 11:10:37 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package neutron - 2:14.0.0-0ubuntu1.1

---------------
neutron (2:14.0.0-0ubuntu1.1) disco; urgency=medium

  [ Corey Bryant ]
  * d/gbp.conf: Create stable/stein branch.

  [ James Page ]
  * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes to
    internal DNS behaviour (LP: #1826419).

 -- Corey Bryant <email address hidden> Tue, 04 Jun 2019 09:39:50 +0100

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/664584
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fb2a4c90a17f0e9272914be53b6c275f8ec3099b
Submitter: Zuul
Branch: stable/stein

commit fb2a4c90a17f0e9272914be53b6c275f8ec3099b
Author: James Page <email address hidden>
Date: Mon Jun 3 09:41:42 2019 +0100

    Revert "Pass network's dns_domain to dnsmasq conf"

    The dns_domain attribute of a network is intended for use
    by neutron when creating DNS records in an external DNS
    system such as Designate.

    By using the networks dns_domain, the configured search
    path on booted instances mismatches with the generated
    dns assignments for instance ports in the hosts file
    for dnsmasq which creates a mismatched forward/reverse
    lookup behaviour.

    This reverts commit 7fdd6adc7acf99e74fbe1c12606f8c867ae134ae.
    and commit 137a6d61053fb1cfb9a0a583b5a5c0f6253c75e6.

    Closes-Bug: 1826419
    Depends-On: I145144c042b100f7e12a02a8ac7e0fbbe41e984d
    Change-Id: I5ff03b5ad8af432a9f7919ef953d7d8c434b93bd

[James Page (james-page)]

This bug was fixed in the package neutron - 2:14.0.0-0ubuntu2~cloud0
---------------

 neutron (2:14.0.0-0ubuntu2~cloud0) bionic-train; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 neutron (2:14.0.0-0ubuntu2) eoan; urgency=medium
 .
   * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes
     to internal DNS behaviour (LP: #1826419).

[James Page (james-page)]

The verification of the Stable Release Update for neutron has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[James Page (james-page)]

This bug was fixed in the package neutron - 2:14.0.0-0ubuntu1.1~cloud0
---------------

 neutron (2:14.0.0-0ubuntu1.1~cloud0) bionic-stein; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 neutron (2:14.0.0-0ubuntu1.1) disco; urgency=medium
 .
   [ Corey Bryant ]
   * d/gbp.conf: Create stable/stein branch.
 .
   [ James Page ]
   * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes to
     internal DNS behaviour (LP: #1826419).

[James Page (james-page)]

The verification of the Stable Release Update for neutron has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[James Page (james-page)]

This bug was fixed in the package neutron - 2:13.0.2-0ubuntu3.3~cloud0
---------------

 neutron (2:13.0.2-0ubuntu3.3~cloud0) bionic-rocky; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 neutron (2:13.0.2-0ubuntu3.3) cosmic; urgency=medium
 .
   * d/p/bug1826419.patch: Cherry pick fix to revert incorrect changes to
     internal DNS behaviour (LP: #1826419).

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/666433

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/rocky
Review: https://review.opendev.org/666594

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/664578
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8b1442c70860091c63f2e343d23105abd19fb6bb
Submitter: Zuul
Branch: master

commit 8b1442c70860091c63f2e343d23105abd19fb6bb
Author: James Page <email address hidden>
Date: Tue Jun 11 14:02:44 2019 +0100

    Release notes for dns_domain behavioural changes

    As part of the fix for bug 1826419, a prior release note was
    deleted and no new release note was added to document the
    change in behaviour as a result of upgrading.

    Add new release note to detail the behaviour of
    {network,conf}.dns_domain with respect to the DHCP agent
    post upgrade.

    The deleted release note will be restored in the stable
    branches where it was removed.

    Change-Id: Ic668d64c28cdc1068cb2413b09839a127bad46d3
    Related-Bug: 1826419

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/664238
Committed: https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=b7f7d1383648f1c61a0a70e983f8afa8e5ac2d14
Submitter: Zuul
Branch: master

commit b7f7d1383648f1c61a0a70e983f8afa8e5ac2d14
Author: James Page <email address hidden>
Date: Mon Jun 10 11:14:25 2019 +0100

    Re-enable internal DNS tests

    Re-enable internal DNS tests as assocaited Neutron
    changes have now landed.

    Assert that 'starwars' has not been configured in
    the search path for the test instance.

    Related-Bug: 1826419
    Change-Id: I9d16f3b2dacd1e753c8f9d803c889c537a3f3378

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/666433
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e3330b10a9f5975a95aa6c3bfba5c77cb8a93b1e
Submitter: Zuul
Branch: stable/stein

commit e3330b10a9f5975a95aa6c3bfba5c77cb8a93b1e
Author: James Page <email address hidden>
Date: Tue Jun 11 14:02:44 2019 +0100

    Release notes for dns_domain behavioural changes

    As part of the fix for bug 1826419, a prior release note was
    deleted and no new release note was added to document the
    change in behaviour as a result of upgrading.

    Restore deleted release note in the stable branches,
    the new note will be added in the master branch.

    Change-Id: Ic668d64c28cdc1068cb2413b09839a127bad46d3
    Related-Bug: 1826419

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/666594
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=feab3462b2bf8b06caba6a15b2311309c6c08a50
Submitter: Zuul
Branch: stable/rocky

commit feab3462b2bf8b06caba6a15b2311309c6c08a50
Author: James Page <email address hidden>
Date: Tue Jun 11 14:02:44 2019 +0100

    Release notes for dns_domain behavioural changes

    As part of the fix for bug 1826419, a prior release note was
    deleted and no new release note was added to document the
    change in behaviour as a result of upgrading.

    Restore deleted release note in the stable branches,
    the new note will be added in the master branch.

    Change-Id: Ic668d64c28cdc1068cb2413b09839a127bad46d3
    Related-Bug: 1826419

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 13.0.4 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 14.0.2 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 12.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 15.0.0.0b1 development milestone.