Comment # 8 on bug 1117483 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.