[ovn] If dhcp port is deleted from neutron, it is never recreated

[Giuseppe Petralia]

This is happening in charmed OpenStack yoga/stable using ovn 22.03.

Neutron version is 2:20.2.0-0ubuntu1

If the dhcp port of a subnet is deleted via OpenStack API, this will never be recreated even toggling the dhcp on the subnet with:

openstack subnet set --no-dhcp/--dhcp <uuid>

This will cause also a missing route for metadata in OVN DHCP_Options:

i.e.

_uuid : 2d4871f5-b675-4978-b291-a1ea7bb5bd4c
cidr : "192.168.100.0/24"
external_ids : {"neutron:revision_number"="1", subnet_id="62b269e0-6668-48ae-9728-aacd7a99df95"}
options : {dns_server="{91.189.91.131, 91.189.91.132}", lease_time="43200", mtu="1500", router="192.168.100.1", server_id="192.168.100.1", server_mac="fa:16:3e:15:13:e6"}

Note the missing classless_static_route="{169.254.169.254/32,192.168.100.2,0.0.0.0/0,192.168.100.1}"

Even if the dhcp port is then recreated manually with device-id ovnmeta-<net-uuid> and device-owner network:distributed, the missing route won't be added to ovn causing VM creation failure.

The routes will appear again in OVN DHCP_Options table only when updating the subnet host-routes with:

openstack subnet set --host-route destination=<subnet>,gateway=<ip-address> <uuid>

[Brian Haley (brian-haley)]

I added neutron to this bug since it seems like there is a difference between ML2/OVS and OVN when it comes to disabling/enabling dhcp on a subnet.

$ openstack port list --fixed-ip subnet=8dc6fc50-7ea1-4165-b8f7-50c331f16060 --device-owner network:dhcp

| 3b0180c8-cee0-445e-937e-ce22c3650422 | | fa:16:3e:2b:94:5d | ip_address='10.0.0.2', subnet_id='8dc6fc50-7ea1-4165-b8f7-50c331f16060'

$ openstack subnet set --no-dhcp 8dc6fc50-7ea1-4165-b8f7-50c331f16060
$ openstack port list --fixed-ip subnet=8dc6fc50-7ea1-4165-b8f7-50c331f16060 --device-owner network:dhcp
<nothing>

$ openstack subnet set --dhcp 8dc6fc50-7ea1-4165-b8f7-50c331f16060
stack@virtualbox-2204:~/devstack$ openstack port list --fixed-ip subnet=8dc6fc50-7ea1-4165-b8f7-50c331f16060 --device-owner network:dhcp

| 3b0180c8-cee0-445e-937e-ce22c3650422 | | fa:16:3e:2b:94:5d | ip_address='10.0.0.2', subnet_id='8dc6fc50-7ea1-4165-b8f7-50c331f16060'

So it was deleted and re-created.

It actually is a very simple change to the OVN code to even *try* to recreate the OVN port, worked with a quick test, so I'll propose a change to neutron for it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/879913

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/879913
Committed: https://opendev.org/openstack/neutron/commit/267efd298479d66c64d55a76bd21c9664080f76a
Submitter: "Zuul (22348)"
Branch: master

commit 267efd298479d66c64d55a76bd21c9664080f76a
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/zed
Review: https://review.opendev.org/c/openstack/neutron/+/880822

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/880823

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/2023.1
Review: https://review.opendev.org/c/openstack/neutron/+/881315

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/881315
Committed: https://opendev.org/openstack/neutron/commit/78a24a3a75f4a365ec4c49e5645d5ca17c2e49b5
Submitter: "Zuul (22348)"
Branch: stable/2023.1

commit 78a24a3a75f4a365ec4c49e5645d5ca17c2e49b5
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/880823
Committed: https://opendev.org/openstack/neutron/commit/47b9511ec5da9b8c8721316f7671bc794c848147
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 47b9511ec5da9b8c8721316f7671bc794c848147
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)
    (cherry picked from commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/880822
Committed: https://opendev.org/openstack/neutron/commit/0681f8b3ad43aafa6e6af521f2b0aaa5923041a1
Submitter: "Zuul (22348)"
Branch: stable/zed

commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 23.0.0.0b2 development milestone.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/883508

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/883534

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/883535

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/883555

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/883534
Committed: https://opendev.org/openstack/neutron/commit/802f03b4de51f5339dc4970381b422107556406e
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 802f03b4de51f5339dc4970381b422107556406e
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)
    (cherry picked from commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1)
    (cherry picked from commit 47b9511ec5da9b8c8721316f7671bc794c848147)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/883555
Committed: https://opendev.org/openstack/neutron/commit/85befc96787a71634576fdc54404e264861997da
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit 85befc96787a71634576fdc54404e264861997da
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Conflicts:
      neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
      neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)
    (cherry picked from commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1)
    (cherry picked from commit 47b9511ec5da9b8c8721316f7671bc794c848147)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/883535
Committed: https://opendev.org/openstack/neutron/commit/d636685f497f5ca2784f92f5d5b8bd24cf35c170
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit d636685f497f5ca2784f92f5d5b8bd24cf35c170
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)
    (cherry picked from commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1)
    (cherry picked from commit 47b9511ec5da9b8c8721316f7671bc794c848147)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/883508
Committed: https://opendev.org/openstack/neutron/commit/5b96edbeef8f76b57be7bd5f93d8c0acfc430a61
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit 5b96edbeef8f76b57be7bd5f93d8c0acfc430a61
Author: Brian Haley <email address hidden>
Date: Fri Apr 7 17:06:40 2023 -0400

    OVN: Always try and create a metadata port on subnets

    When a subnet is updated, for example, to disable then
    re-enable DHCP on it, if there is no metadata port it
    will just return without trying to allocate an IP,
    leaving DHCP unusable on the subnet. This could happen
    if an admin, even accidentally, deletes the DHCP port
    on a subnet while DHCP is disabled.

    This also makes OVN behave like ML2/OVS, which will
    re-create the DHCP port when the enable_dhcp flag is
    changed to false and back to true.

    Conflicts:
      neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
      neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py
      neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py

    Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
    Closes-bug: #2015377
    (cherry picked from commit 267efd298479d66c64d55a76bd21c9664080f76a)
    (cherry picked from commit 0681f8b3ad43aafa6e6af521f2b0aaa5923041a1)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron ussuri-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron victoria-eom release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron wallaby-eom release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron xena-eom release.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.