[Bug 1117483] New: openvswitch: please consider dropping the use of DISABLE_STOP_ON_REMOVAL/DISABLE_RESTART_ON_UPDATE
http://bugzilla.suse.com/show_bug.cgi?id=1117483 Bug ID: 1117483 Summary: openvswitch: please consider dropping the use of DISABLE_STOP_ON_REMOVAL/DISABLE_RESTART_ON_UPDATE Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening@forge.provo.novell.com Reporter: fbui@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Hi Jaime, After a discussion with Markos, it appears that the use of both DISABLE_STOP_ON_REMOVAL=yes and DISABLE_RESTART_ON_UPDATE=yes in openvswitch.spec is not needed at all. Regarding DISABLE_RESTART_ON_UPDATE=yes and according to Markos, OVS services can now be restarted on package updates because "it's being handled by the upper layers from crowbar or whatever else management tool they use". Even if the package would still need to be restarted on updates, %systemd_postun_with_restart() or %systemd_postun() macros should be used instead of the env variable. Regarding DISABLE_STOP_ON_REMOVAL=yes: this was actually an "addon" on the previous issue but it's not needed at all. It would be nice if it could be dropped especially since a) leaving a daemon running while all its files (binaries, libs, config files, etc...) have been deleted may obviously lead to crashes b) one can expect that the network is going down if a package such as openvswitch is removed. 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 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchandras@suse.com Assignee|bnc-team-screening@forge.pr |jcaamano@suse.com |ovo.novell.com | -- 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#c1 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mchandras@suse.co | |m) --- Comment #1 from Franck Bui <fbui@suse.com> --- 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#c2 Markos Chandras <mchandras@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mchandras@suse.co | |m) | --- Comment #2 from Markos Chandras <mchandras@suse.com> --- Jaime this one is for you :) Let me know if you need any help -- 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 <jcaamano@suse.com> --- 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#c4 --- Comment #4 from Franck Bui <fbui@suse.com> --- No urgency (although it would be nice if it could be addressed in the next month) I just wanted to make sure that this issue won't get lost: it was opened more than 1 month ago and it didn't receive any update since now. 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#c5 --- Comment #5 from Swamp Workflow Management <swamp@suse.de> --- 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#c7 Jaime Caamaño Ruiz <jcaamano@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jaime Caamaño Ruiz <jcaamano@suse.com> --- Change submitted to Factory. -- 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 <jcaamano@suse.com> 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 <jcaamano@suse.com> --- 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#c9 --- Comment #9 from Jaime Caamaño Ruiz <jcaamano@suse.com> --- The use of %service_del_postun macro and the DISABLE_RESTART_ON_UPDATE is documented on the systemd package guidelines [1], so I think it's fine to use them. I think also that %service_* macros are the intended ones to be used by packages providind services, as are the one that account for systemd presets. [1] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines -- 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 <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fbui@suse.com) | --- Comment #10 from Franck Bui <fbui@suse.com> --- (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#c11 --- Comment #11 from Franck Bui <fbui@suse.com> --- (In reply to Jaime Caamaño Ruiz from comment #9)
The use of %service_del_postun macro and the DISABLE_RESTART_ON_UPDATE is documented on the systemd package guidelines [1], so I think it's fine to use them.
I don't think so and I think the wiki should be updated in order to remove the use of DISABLE_RESTART_ON_UPDATE. -- 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 <jcaamano@suse.com> ---
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#c13 --- Comment #13 from Franck Bui <fbui@suse.com> --- (In reply to Jaime Caamaño Ruiz from comment #12)
So we have good reasons to go either way.
No. We should not try to promote or claim that using DISABLE_RESTART_ON_UPDATE will magically make things work. Again DISABLE_RESTART_ON_UPDATE put services in inconsistent states. 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. -- 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 <jcaamano@suse.com> --- 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#c15 --- Comment #15 from Franck Bui <fbui@suse.com> --- (In reply to Jaime Caamaño Ruiz from comment #14)
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.
In *general* I think so.
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?
From my point of view, the hack is the API proposed by SUSE to allow turning
Sorry it seems that I'm not clear neither ;) the restart of services *globally* via a environment variable DISABLE_RESTART_ON_UPDATE. IOW if this variable is set to yes (via /etc/sysconfig/xxx), then *all* packages won't restart on update which really sounds wrong and dangerous. Services might need to prevent restarting on update (although the only "valid" use case I can see is that the service doesn't support restarting yet) but in this case this should be done at the package level not through a global environment variable like it's proposed currently. Giving the illusion to sysadmin that setting globally DISABLE_RESTART_ON_UPDATE=yes will magically work is a bad idea IMHO. 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. Hope that makes more sense. -- 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 <jcaamano@suse.com> ---
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#c17 --- Comment #17 from Franck Bui <fbui@suse.com> --- (In reply to Jaime Caamaño Ruiz from comment #16)
%service_del_postun macro accepts parameter -n to same effect. But the result is not very explicit, arguably less than the environment variable :(
That's one of the reason why I would prefer introducing something like "%service_del_postun_without_restart" which should be a hint that it's not the default macros in %postun to use and would allow at least get rid of the global environment variable. And IIRC openvswitch was one of the few users, hence this BZ report. -- 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 <jcaamano@suse.com> --- 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#c19 --- Comment #19 from Franck Bui <fbui@suse.com> --- Well as maintainer of systemd-rpm-macros and for the reasons given above, we want to get rid of DISABLE_RESTART_ON_UPDATE. There were already some discussion about this subject that happened on @systemd-maintainers mailing list. 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 ? -- 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 <jcaamano@suse.com> --- (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#c21 --- Comment #21 from Franck Bui <fbui@suse.com> --- (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?
Yes please do so as a first step even if I believe this option will be useless once we will get rid of the env var completely. I'll introduce a new macro which will be the counterpart of %systemd_postun_with_restart. It would be nice if you could switch to it eventually. BTW couldn't openvswitch use the upstream macros ? do you 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#c22 --- Comment #22 from Jaime Caamaño Ruiz <jcaamano@suse.com> ---
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#c23 --- Comment #23 from Franck Bui <fbui@suse.com> --- While at it, could you drop the use of $FIRST_ARG in openvswitch.spec. As discussed via email, there's no point to rely on this "magic" variable set indirectly by systemd rpm macros, simply using "$1" works and is more readable IMHO. -- 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 <fbui@suse.com> --- (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#c26 --- Comment #26 from Franck Bui <fbui@suse.com> --- Jaime, do you plan to push the changes to Factory as well soon ? (after all this bug was opened against this distro) -- 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 <jcaamano@suse.com> --- (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#c29 Jaime Caamaño Ruiz <jcaamano@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #29 from Jaime Caamaño Ruiz <jcaamano@suse.com> --- - DISABLE_STOP_ON_REMOVAL was removed. - DISABLE_RESTART_ON_UPDATE was replaced with '%service_del_postun -n' and will be replaced with %service_del_postun_without_restart in next package update. - $FIRST_ARG was replaced with $1. Submitted to Factory and SLES15 SP1. -- 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 <fbui@suse.com> --- 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#c31 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #31 from Franck Bui <fbui@suse.com> --- Hi Jaime, (In reply to Jaime Caamaño Ruiz from comment #29)
- DISABLE_RESTART_ON_UPDATE was replaced with '%service_del_postun -n' and will be replaced with %service_del_postun_without_restart in next package update.
Could you do so as %service_del_postun_without_restart has been introduced in Factory, SLE12-SP2+, SLE15+ ? 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 <junguo.wang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junguo.wang@suse.com --- Comment #39 from jun wang <junguo.wang@suse.com> --- 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#c40 --- Comment #40 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2021:0277-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 Linux Enterprise Server for SAP 15 (src): openvswitch-2.11.5-6.30.2 SUSE Linux Enterprise Server 15-LTSS (src): openvswitch-2.11.5-6.30.2 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): openvswitch-2.11.5-6.30.2 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): openvswitch-2.11.5-6.30.2 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#c41 --- Comment #41 from Jaime Caama�o Ruiz <jcaamano@suse.com> --- (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#c42 --- Comment #42 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2021:0284-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 OpenStack Cloud Crowbar 8 (src): openvswitch-2.7.12-3.36.1 SUSE OpenStack Cloud 8 (src): openvswitch-2.7.12-3.36.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): openvswitch-2.7.12-3.36.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): openvswitch-2.7.12-3.36.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): openvswitch-2.7.12-3.36.1 SUSE Enterprise Storage 5 (src): openvswitch-2.7.12-3.36.1 HPE Helion Openstack 8 (src): openvswitch-2.7.12-3.36.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#c43 --- Comment #43 from jun wang <junguo.wang@suse.com> --- (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#c44 --- Comment #44 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2021:0298-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 OpenStack Cloud 7 (src): openvswitch-2.5.11-25.26.1, openvswitch-dpdk-2.5.11-25.26.1 SUSE Linux Enterprise Server for SAP 12-SP2 (src): openvswitch-2.5.11-25.26.1, openvswitch-dpdk-2.5.11-25.26.1 SUSE Linux Enterprise Server 12-SP2-LTSS (src): openvswitch-2.5.11-25.26.1, openvswitch-dpdk-2.5.11-25.26.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): openvswitch-2.5.11-25.26.1, openvswitch-dpdk-2.5.11-25.26.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#c45 --- Comment #45 from Swamp Workflow Management <swamp@suse.de> --- 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#c46 --- Comment #46 from Swamp Workflow Management <swamp@suse.de> --- SUSE-SU-2021:0297-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 OpenStack Cloud Crowbar 9 (src): openvswitch-2.8.10-4.23.1 SUSE OpenStack Cloud 9 (src): openvswitch-2.8.10-4.23.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): openvswitch-2.8.10-4.23.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): openvswitch-2.8.10-4.23.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 <swamp@suse.de> --- 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.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com