[neutron][stable] Backport of the patch which bumps RPC version
Hi, Some time ago we backported in Neutron patch [1] which caused bug [2]. Patch [1] was merged in the Ussuri development cycle so it is already in Ussuri and Victoria. Our mistake was that we merged it then without bump of the RPC version and without code which would provide backward compatybility between old agent and new neutron-server and that's why [2] happens. Now, as we know that, we have proposed patch [3] to fix it in master branch. And my question is - can we backport fix [3] to the stable/victoria and stable/ ussuri to fix the original issue caused by [1] there? In general I know that we shouldn't do that but here are the reasons why we would like to do it in this specific case: - rpc version which we want to change now wasn't changed since Train at least so there will be no any conflict with that, - bump rpc version now and provide backward compatybility on neutron-server will make upgrades Train->Ussuri and minor updates in Ussuri easier as there will be no similar issue like is described in [2] anymore, - patch [1] was already included in Ussuri and Victoria from master branch, it wasn't really cherry-picked there so it actually should be there since the beginning. Based on those reasons mentioned about and also becuase in general it is forbiden by stable policy to backport changes like that to stable branches I would like to know opinion from wider community, especially stable-core-maint team, about what would be the best approach to fix that issue: backport of [3] to stable/{ussuri,victoria} or revert [1] in stable/{ussuri,victoria}. [1] https://review.opendev.org/c/openstack/neutron/+/712632 [2] https://bugs.launchpad.net/neutron/+bug/1903531 [3] https://review.opendev.org/c/openstack/neutron/+/764108 -- Slawek Kaplonski Principal Software Engineer Red Hat
Hi Slawek, Thanks for turning to the mailing list with this issue and for the explanation! In short: from stable core viewpoint I think this case could get an exception and we could merge back patch [3] to Victoria and Ussuri. Here is my thinking: - If I understand correctly, the critical code change ([1]) is already there in many release, in Ussuri (16.0.0, 16.1.0, 16.2.0) and Victoria (17.0.0). So I think it would not be fortunate to revert the code change, because it could cause some similar issue. (RPC change. Am I right?) - The code change is there from Ussuri, which means actually the RPC has changed already, only the versioning is missed. - Also, as you wrote, it would mean easier upgrades to backport patch [3]. - Those, who already upgraded from Train to Ussuri probably bumped into the issue, so in case the change is reverted they will face an issue again. Based on these and what you wrote I think now the less problematic way forward if we take an exception and propose + merge the backports. If anyone has any other opinion or objection or sees any technical issue we haven't thought of, then let us know! Thanks, Előd On 2020. 12. 02. 18:51, Slawek Kaplonski wrote:
Hi,
Some time ago we backported in Neutron patch [1] which caused bug [2]. Patch [1] was merged in the Ussuri development cycle so it is already in Ussuri and Victoria. Our mistake was that we merged it then without bump of the RPC version and without code which would provide backward compatybility between old agent and new neutron-server and that's why [2] happens.
Now, as we know that, we have proposed patch [3] to fix it in master branch. And my question is - can we backport fix [3] to the stable/victoria and stable/ ussuri to fix the original issue caused by [1] there? In general I know that we shouldn't do that but here are the reasons why we would like to do it in this specific case: - rpc version which we want to change now wasn't changed since Train at least so there will be no any conflict with that, - bump rpc version now and provide backward compatybility on neutron-server will make upgrades Train->Ussuri and minor updates in Ussuri easier as there will be no similar issue like is described in [2] anymore, - patch [1] was already included in Ussuri and Victoria from master branch, it wasn't really cherry-picked there so it actually should be there since the beginning.
Based on those reasons mentioned about and also becuase in general it is forbiden by stable policy to backport changes like that to stable branches I would like to know opinion from wider community, especially stable-core-maint team, about what would be the best approach to fix that issue: backport of [3] to stable/{ussuri,victoria} or revert [1] in stable/{ussuri,victoria}.
[1] https://review.opendev.org/c/openstack/neutron/+/712632 [2] https://bugs.launchpad.net/neutron/+bug/1903531 [3] https://review.opendev.org/c/openstack/neutron/+/764108
Hi, Thx a lot Előd for Your input on this topic. On Thu, Dec 03, 2020 at 04:00:31PM +0100, Előd Illés wrote:
Hi Slawek,
Thanks for turning to the mailing list with this issue and for the explanation!
In short: from stable core viewpoint I think this case could get an exception and we could merge back patch [3] to Victoria and Ussuri.
Here is my thinking:
- If I understand correctly, the critical code change ([1]) is already there in many release, in Ussuri (16.0.0, 16.1.0, 16.2.0) and Victoria (17.0.0). So I think it would not be fortunate to revert the code change, because it could cause some similar issue. (RPC change. Am I right?) - The code change is there from Ussuri, which means actually the RPC has changed already, only the versioning is missed. - Also, as you wrote, it would mean easier upgrades to backport patch [3]. - Those, who already upgraded from Train to Ussuri probably bumped into the issue, so in case the change is reverted they will face an issue again.
Yes. All those points are correct.
Based on these and what you wrote I think now the less problematic way forward if we take an exception and propose + merge the backports.
That is our understanding too and that's why I asked for that here :)
If anyone has any other opinion or objection or sees any technical issue we haven't thought of, then let us know!
Thanks,
Előd
On 2020. 12. 02. 18:51, Slawek Kaplonski wrote:
Hi,
Some time ago we backported in Neutron patch [1] which caused bug [2]. Patch [1] was merged in the Ussuri development cycle so it is already in Ussuri and Victoria. Our mistake was that we merged it then without bump of the RPC version and without code which would provide backward compatybility between old agent and new neutron-server and that's why [2] happens.
Now, as we know that, we have proposed patch [3] to fix it in master branch. And my question is - can we backport fix [3] to the stable/victoria and stable/ ussuri to fix the original issue caused by [1] there? In general I know that we shouldn't do that but here are the reasons why we would like to do it in this specific case: - rpc version which we want to change now wasn't changed since Train at least so there will be no any conflict with that, - bump rpc version now and provide backward compatybility on neutron-server will make upgrades Train->Ussuri and minor updates in Ussuri easier as there will be no similar issue like is described in [2] anymore, - patch [1] was already included in Ussuri and Victoria from master branch, it wasn't really cherry-picked there so it actually should be there since the beginning.
Based on those reasons mentioned about and also becuase in general it is forbiden by stable policy to backport changes like that to stable branches I would like to know opinion from wider community, especially stable-core-maint team, about what would be the best approach to fix that issue: backport of [3] to stable/{ussuri,victoria} or revert [1] in stable/{ussuri,victoria}.
[1] https://review.opendev.org/c/openstack/neutron/+/712632 [2] https://bugs.launchpad.net/neutron/+bug/1903531 [3] https://review.opendev.org/c/openstack/neutron/+/764108
-- Slawek Kaplonski Principal Software Engineer Red Hat
participants (2)
-
Előd Illés
-
Slawek Kaplonski