Bug 2107602
Summary: | neutron revision_number does not bump on network update | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Andreas Karis <akaris> | |
Component: | openstack-neutron | Assignee: | Slawek Kaplonski <skaplons> | |
Status: | CLOSED ERRATA | QA Contact: | Eran Kuris <ekuris> | |
Severity: | low | Docs Contact: | ||
Priority: | low | |||
Version: | 16.2 (Train) | CC: | chrisw, jlibosva, mlavalle, mtomaska, scohen | |
Target Milestone: | z4 | Keywords: | Reopened, Triaged | |
Target Release: | 16.2 (Train on RHEL 8.4) | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | openstack-neutron-15.3.5-2.20221005184727.c81fb5b.el8ost | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 2122128 2125541 (view as bug list) | Environment: | ||
Last Closed: | 2022-12-07 19:27:22 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2122128, 2125541 |
Description
Andreas Karis
2022-07-15 13:58:28 UTC
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 |