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.