http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c1 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mchandras@suse.co | |m) --- Comment #1 from Franck Bui --- Jaime, Markos, any updates on this one ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c3 --- Comment #3 from Jaime Caamaño Ruiz --- Hi, yes, got this. Waiting on having some other changes to add this. Is there any urgency for a reason I might be missing? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c5 --- Comment #5 from Swamp Workflow Management --- This is an autogenerated message for OBS integration: This bug (1117483) was mentioned in https://build.opensuse.org/request/show/668409 Factory / openvswitch -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c8 Jaime Caamaño Ruiz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |fbui@suse.com Resolution|FIXED |--- Flags| |needinfo?(fbui@suse.com) --- Comment #8 from Jaime Caamaño Ruiz --- I think I need to revisit this one. On removing DISABLE_STOP_ON_REMOVAL, I agree. About DISABLE_RESTART_ON_UPDATE: When a node is going to be upgraded, what I think to be the normal thing to do is to commission it out of production, do the maintenance, and then do whatever provisioning steps are required on the node to put it back in production. That is because, even if "it's being handled by the upper layers from crowbar or whatever else management tool they use", you wont risk the traffic interruption which will most likely happen. I don't see a real use case in avoiding restart. It might be useful if you made a mistake giving you the chance to downgrade again if you upgraded by mistake. Or maybe, reduce the downtime by being able to install updates as a pre-step of commissioning and downtime. But I also don't see a compelling reason to change it, opposite to what is proposed upstream and what the default systemd macro does, and risk other problems. Faik, what are your motivations to change it? The other matter is using the service_del_postun macro (which honours DISABLE_RESTART_ON_UPDATE variable) vs systemd_postun_with_restart/systemd_postun macros. While I understand using the systemd macros is preferable, I guess there is a reason why service_del_postun exists and is being used. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c10 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui@suse.com) | --- Comment #10 from Franck Bui --- (In reply to Jaime Caamaño Ruiz from comment #8)

I think I need to revisit this one.

On removing DISABLE_STOP_ON_REMOVAL, I agree.

About DISABLE_RESTART_ON_UPDATE:

[...]

I don't see a real use case in avoiding restart. [...]

But I also don't see a compelling reason to change it, [...]

So it seems that you have mixed opinion about DISABLE_RESTART_ON_UPDATE... Let's me add another argument against it: when service restarting is disabled while upgrading the service package, you're in an inconsistent state. The version of the running daemon doesn't match the one stored on disk and any attempt for the daemon to run libraries, conf files might fail or lead to a crash in the worst scenario... Very few packages (maybe none) need this "feature" and if it was really needed we shouldn't encourage this practice and make it part of the macro API. Instead concerned packages should implement their own stuff. So DISABLE_RESTART_ON_UPDATE is a hack IMHO, and there are much better ways to implement the zero downtime mechanism these days.

While I understand using the systemd macros is preferable, I guess there is a reason why service_del_postun exists and is being used.

The only reason for them is to keep backward compatibilities with SysV init. So basically if you're maintaining a package that was providing SysV init scripts which were then later converted in systemd unit files then you should use the SUSE macros otherwise there's no point and the upstream versions should be preferred as it makes your package portable across various distros. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c12 --- Comment #12 from Jaime Caamaño Ruiz ---

when service restarting is disabled while upgrading the service package, you're in an inconsistent state. The version of the running daemon doesn't match the one stored on disk and any attempt for the daemon to run libraries, conf files might fail or lead to a crash in the worst scenario...

I agree. So on one side we have this problem (and we have 'zypper ps' warning to check it). On the other side, if we restart, the information stored on OVS database is lost, which on a second thought, still may affect ovs standalone users since not all of them will be running an upper management tool and from an ovs package perspective we probably should not make such assumptions. So we have good reasons to go either way.

The only reason for them is to keep backward compatibilities with SysV init. So >basically if you're maintaining a package that was providing SysV init scripts which were then later converted in systemd unit files then you should use the SUSE macros otherwise there's no point and the upstream versions should be preferred as it makes your package portable across various distros.

Understood. It looks like that is the case for the SLES11 upgrade path.

Very few packages (maybe none) need this "feature" and if it was really needed we >shouldn't encourage this practice and make it part of the macro API. Instead concerned >packages should implement their own stuff.

I don't understand the problem with the macro API. We could use %service_del_postun -n" instead of DISABLE_RESTART_ON_UPDATE. %systemd_postun would behave in the same way. --- However, where I wanted to get to if this corresponds to a real need or problem that we have in our field systems or labs. If we have no other reasons, then someone can come back later with a different opinion and then we are in a spiral of changing it back and forth. Why don't we accept the status quo that we have now until we have a good reason to go one way or the other. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c14 --- Comment #14 from Jaime Caamaño Ruiz --- It seems that I am failing miserably on explaining myself. One last attempt.

We should not try to promote or claim that using DISABLE_RESTART_ON_UPDATE will >magically make things work.

I never claimed that. I just tried to explain there are reasons to consider not restarting the service. I take it that you have a strong opinion that leaving the old service running is the worst option.

The macros are for the common cases, if any package chooses to implement >something hackish for their restart then they should implement that in their >own.

There is not need to implement anything hackish. Upstream %systemd_postun macro "as is" does not restart the service. What is the hack exactly? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c16 --- Comment #16 from Jaime Caamaño Ruiz ---

But yes a better alternative would be to provide a new macro (similarly to what upstream does) whose name would explicitly tell that restarting is not done.

Agreed. The macro being used, %service_del_postun, reads DISABLE_RESTART_ON_UPDATE both from environment and from /etc/sysconfig/services. %service_del_postun macro accepts parameter -n to same effect. But the result is not very explicit, arguably less than the environment variable :( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c18 --- Comment #18 from Jaime Caamaño Ruiz --- I think that much of this discussion should be directed to the systemd-rpm-macros package. If there is some kind of agreement there that DISABLE_RESTART_ON_UPDATE should be dropped in favor of some other more explicit macro, then I would have no problems helping with that. If the current use of DISABLE_RESTART_ON_UPDATE in openvswitch package is preventing to move the discussion forward, we can replace it with '%service_del_postun -n'. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c20 --- Comment #20 from Jaime Caamaño Ruiz --- (In reply to Franck Bui from comment #19)

Could you give me the status of openvswitch ?

Does it still use DISABLE_RESTART_ON_UPDATE ? if so why exactly and how a sysadmin is supposed to use it ? by globally disable the restart of all packages ?

We use DISABLE_RESTART_ON_UPDATE=yes on spec %postun section before using the %service_del_postun macro. This is not a global use of DISABLE_RESTART_ON_UPDATE and only affects services handled in openvswitch package. sysadmin is not expected to do anything other than restarting the affected upgraded services at his convenience. The affected services handled in the openvswitch package are: ovsdb-server.service ovs-vswitchd.service openvswitch.service ovn-northd.service ovn-controller.service ovn-controller-vtep.service openvswitch-testcontroller.service For the first three listed services, the purpose of preventing the restart is to avoid inadvertent loss of information that could happen upon restart. This is aligned to the upstream approach. I am unsure about the other services, but probably the use of DISABLE_RESTART_ON_UPDATE could be dropped for those.

Well as maintainer of systemd-rpm-macros and for the reasons given above, we >want to get rid of DISABLE_RESTART_ON_UPDATE.

We can stop using DISABLE_RESTART_ON_UPDATE. We can use '%service_del_postun -n' instead. Is that OK? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c22 --- Comment #22 from Jaime Caamaño Ruiz ---

BTW couldn't openvswitch use the upstream macros ? do you need to deal with SysV init script migration ?

I think we have an upgrade path from SLE11 for which we need to deal with SysV init script migration. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c25 --- Comment #25 from Franck Bui --- (In reply to Jaime Caamaño Ruiz from comment #20)

We can stop using DISABLE_RESTART_ON_UPDATE. We can use '%service_del_postun -n' instead. Is that OK?

FYI, I submitted a new macro "%service_del_postun_without_restart" which has the same effect. It should reach Factory (only) during the next week. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c27 --- Comment #27 from Jaime Caamaño Ruiz --- (In reply to Franck Bui from comment #26)

Jaime, do you plan to push the changes to Factory as well soon ? (after all this bug was opened against this distro)

Yes, I will submit to Factory as well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1117483 http://bugzilla.suse.com/show_bug.cgi?id=1117483#c30 --- Comment #30 from Franck Bui --- Good job, thanks ! -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1117483 https://bugzilla.suse.com/show_bug.cgi?id=1117483#c39 jun wang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junguo.wang@suse.com --- Comment #39 from jun wang --- I am testing openvswitch update SUSE:Maintenance:17066:234825, it seems that one of "%service_del_postun" was not replaced by "%service_del_postun_without_restart": https://build.suse.de/package/view_file/SUSE:Maintenance:17066/openvswitch.S... (line 426). is this expected on SLES12SP2 ? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1117483 https://bugzilla.suse.com/show_bug.cgi?id=1117483#c41 --- Comment #41 from Jaime Caama�o Ruiz --- (In reply to jun wang from comment #39)

I am testing openvswitch update SUSE:Maintenance:17066:234825, it seems that one of "%service_del_postun" was not replaced by "%service_del_postun_without_restart": https://build.suse.de/package/view_file/SUSE:Maintenance:17066/openvswitch. SUSE_SLE-12-SP2_Update/openvswitch.spec?rev=4 (line 426).

is this expected on SLES12SP2 ?

I guess we are replacing "%service_del_postun -n" not "%service_del_postun". Does it make sense? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1117483 https://bugzilla.suse.com/show_bug.cgi?id=1117483#c43 --- Comment #43 from jun wang --- (In reply to Jaime Caama�o Ruiz from comment #41)

(In reply to jun wang from comment #39) I guess we are replacing "%service_del_postun -n" not "%service_del_postun". Does it make sense?

I checked the changelog, yes, we replaced "%service_del_postun -n". Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1117483 https://bugzilla.suse.com/show_bug.cgi?id=1117483#c45 --- Comment #45 from Swamp Workflow Management --- SUSE-SU-2021:0300-1: An update that solves one vulnerability and has one errata is now available. Category: security (important) Bug References: 1117483,1181345 CVE References: CVE-2020-27827 JIRA References: Sources used: SUSE Manager Server 4.0 (src): openvswitch-2.11.5-3.12.1 SUSE Manager Retail Branch Server 4.0 (src): openvswitch-2.11.5-3.12.1 SUSE Manager Proxy 4.0 (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise Server for SAP 15-SP1 (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise Server 15-SP1-LTSS (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise Server 15-SP1-BCL (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP3 (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP2 (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): openvswitch-2.11.5-3.12.1 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): openvswitch-2.11.5-3.12.1 SUSE Enterprise Storage 6 (src): openvswitch-2.11.5-3.12.1 SUSE CaaS Platform 4.0 (src): openvswitch-2.11.5-3.12.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1117483 https://bugzilla.suse.com/show_bug.cgi?id=1117483#c47 --- Comment #47 from Swamp Workflow Management --- openSUSE-SU-2021:0239-1: An update that solves one vulnerability and has one errata is now available. Category: security (important) Bug References: 1117483,1181345 CVE References: CVE-2020-27827 JIRA References: Sources used: openSUSE Leap 15.2 (src): openvswitch-2.13.2-lp152.3.9.1 -- You are receiving this mail because: You are on the CC list for the bug.