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

Bug #2015377 reported by Giuseppe Petralia
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Brian Haley
neutron (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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>

Changed in neutron:
assignee: nobody → Brian Haley (brian-haley)
importance: Undecided → Medium
tags: added: ovn
Revision history for this message
Brian Haley (brian-haley) wrote :

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.

Changed in neutron:
status: New → Confirmed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

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

Changed in neutron:
status: Confirmed → In Progress
summary: - If dhcp port is deleted from neutron, it is never recreated
+ [ovn] If dhcp port is deleted from neutron, it is never recreated
tags: added: antelope-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

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

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/zed)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/yoga)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/2023.1)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/2023.1)

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)

tags: added: in-stable-yoga
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/yoga)

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)

tags: added: in-stable-zed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/zed)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 23.0.0.0b2

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/ussuri)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/xena)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/wallaby)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/victoria)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/xena)

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)

tags: added: in-stable-xena
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/victoria)

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)

tags: added: in-stable-victoria
tags: added: in-stable-wallaby
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/wallaby)

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)

tags: added: in-stable-ussuri
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/ussuri)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 22.0.1

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 21.1.1

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 20.3.1

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron ussuri-eol

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron victoria-eom

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron wallaby-eom

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron xena-eom

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in neutron (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.