Description of problem: neutron revision_number does not bump on network update neutron revision_number does not bump on network update I tested the exact same mechanism with the subnet resource and an update to the same field (description) and it works like a charm. For the network resource, the revision number is not updated when updating the description field, instead there's an inconsitency checker which fixesthe inconsistency from time to time Please see https://bugs.launchpad.net/neutron/+bug/1981817 for full details Version-Release number of selected component (if applicable): [stack@standalone gophercloud-test]$ sudo podman ps | grep neutron c0f71c87753a registry-proxy.engineering.redhat.com/rh-osbs/rhosp16-openstack-neutron-server-ovn:16.2_20220609.1 kolla_start 4 days ago Up 4 days ago neutron_api 8002f415d5c4 registry-proxy.engineering.redhat.com/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20220609.1 kolla_start 4 days ago Up 4 days ago ovn_metadata_agent 0bc5974e8fb8 registry-proxy.engineering.redhat.com/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20220609.1 /bin/bash -c HAPR... 4 days ago Up 4 days ago neutron-haproxy-ovnmeta-b9cfe6b5-831b-419c-bc25-49ba01a33c84 578bb7cab9d2 registry-proxy.engineering.redhat.com/rh-osbs/rhosp16-openstack-neutron-metadata-agent-ovn:16.2_20220609.1 /bin/bash -c HAPR... 38 hours ago Up 38 hours ago neutron-haproxy-ovnmeta-ed889e25-f8fa-4684-a9c4-54fff8de37b8 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Next step is to analyze how subnets updates also require an update in the network. If that is confirmed, this bz is not a bug and can be closed along with the corresponding U/S Launchpad bug
I checked in in the neutron code. Subnet's revision is bumped "on puprose". It was done with commit https://github.com/openstack/neutron/commit/5264ab966d3db7b1cb698190872cbe6feaf48464 to fix bug https://bugs.launchpad.net/neutron/+bug/1532695 - if we would like to get rid of this network's revision_number bump when subnet is created we would need to solve that bug in some other way which may not be trivial. Later it was also optimized with https://github.com/openstack/neutron/commit/bc306a5512dc7d46737f1822cd2f827f87b95f9c but general idea is still the same. Now, for other resources, I found out that commit https://github.com/openstack/neutron/commit/e9a7ed8c63ec5bb0fdca3406c8b21071729dd09d introduced something similar for ports - when port was created or deleted, network's revision number was bumped too. But this was reverted with commit https://review.opendev.org/c/openstack/neutron/+/591847 to fix bug https://bugs.launchpad.net/kuryr-libnetwork/+bug/1787028 So we have 2 possibilities to make all that behaviour consistent across all resources: 1. Stop bumping network's revision number when subnet is created - but that will require to solve https://bugs.launchpad.net/neutron/+bug/1532695 in different way first, 2. Keep current "subnet and network" behaviour like it is now, identify all other relationships and implement revision bumps for all of them - this can be even harder to do then proposal 1. and may have some unpredictable side effects e.g. for the ovn mechanism driver which relies on revision numbers a lot. So regarding all of that what I wrote above and giving that this is low priority and severity bug I'm going to close it as "WONTFIX".
Thanks for the analysis Slawek. I think there's a misunderstanding here: I found a bug where the revision number does not increase at all on the network resource, even though I change the network's description field. Check the upstream bug for a reproducer instruction. It didn't happen to me all of the time, but during that specific test that I posted upstream, the following series would lead to the same revision number: $ openstack net create net0 -f value -c revision_number 1 $ openstack net set net0 --description foo $ openstack net show net0 -f value -c revision_number # revision number stays the same
Omg, bad typo, sorry for that. In the description field, it should have been: "I tested the exact same mechanism with the subnet resource and an update to the same field (description) and it works like a charm. For the network resource, the revision number is not updated when updating the field, instead there's an inconsitency checker which fixes the inconsistency from time to time"
Also just further clarifition: I found this issue with RHOSP 16.2, see the first comment for the container versions.
Thx Andreas for explanation. I took another look at it and it seems that it's the same issue like reported in https://bugs.launchpad.net/neutron/+bug/1865173 for router object. I proposed patch https://review.opendev.org/c/openstack/neutron/+/851733 which should fix both of those issues together.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Red Hat OpenStack Platform 16.2.4 (openstack-neutron) security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:8855