Open Stack

With a stable maintainer hat on, i have to say that both Jeremy and 
Ghanshyam are right:

- in general, backporting default config value changes are not allowed 
according to stable policy
- in some situations, though, if there are other reasons / it is more 
beneficial to backport the patch (based on thorough consideration by the 
team) then the team can make an exception and backport it anyway

So in this case that should be considered (as Ghanshyam wrote), whether 
it could have worked for some components, and what impact could it have, 
and maybe it is safer to not backport but inform the operators to change 
the config value for the failing cases.

Cheers,
Előd


On 2022. 08. 05. 20:17, Ghanshyam Mann wrote:
>   ---- On Fri, 05 Aug 2022 17:54:25 +0530  Slawek Kaplonski  wrote ---
>   > Hi,
>   >
>   > Some time ago oslo.messaging changed default value of the "heartbeat_in_pthread" config option to "True" [1].
>   > As was noticed some time ago, this don't works well with nova-compute - see bug [2] for details.
>   > Recently we noticed in our downstream Red Hat OpenStack, that it's not only nova-compute which don't works well with it and can hangs. We saw the same issue in various neutron agent processes. And it seems that it can be the same for any non-wsgi service which is using rabbitmq to send heartbeats.
>   > So giving all of that, I just proposed change of the default value of that config option to be "False" again [3].
>   > And my question is - would it be possible and acceptable to backport such change up to stable/wallaby (if and when it will be approved for master of course). IMO this could be useful for users as using this option set as "True" be default don't makes any sense for the non-wsgi applications really and may cause more bad then good things really. What are You opinions about it?
>
> This is tricky, in general the default value change should not be backported because it change
> the default behavior and so does the compatibility. But along with considering the cases do not
> work with the current default value (you mentioned in this email), we should consider if this worked
> in any other case or not. If so then I think we should not backport this and tell operator to override
> it to False as workaround for stable branch fixes.
>
> -gmann
>
>   >
>   > [1] https://review.opendev.org/c/openstack/oslo.messaging/+/747395
>   > [2] https://bugs.launchpad.net/oslo.messaging/+bug/1934937
>   > [3] https://review.opendev.org/c/openstack/oslo.messaging/+/852251/
>   >
>   > --
>   > Slawek Kaplonski
>   > Principal Software Engineer
>   > Red Hat
>