In RHEL7-OSP5 and later, we ship the following two OCF resources: - NetnsCleanup.ocf_ra - OVSCleanup.ocf_ra Quoting the headers of the files: # This file is used/cloned in EL6 + EL7, please upgrade both branches # when that's necessary. # # reason: systemd one-shot scripts only accept the start verb, and # always report themselves as dead. We need support for that on # systemd to get rid of this on EL7 + HA/pacemaker. Actually, systemd supports one-shot scripts that do not report themselves as dead, via RemainAfterExit=yes directive. So instead of copy-pasting those SysV-scripts from EL6, we could utilize systemd feature, avoiding redundant shell code from the package.
Good catch!, Adding support for this, but then we need to change the deployment tools to use back systemd resources before removing this.
Checked, and it works at least individually, may need extra testing at integration time with pacemaker. How to test, (RHEL7 only as this change is RHEL7 only): 1) service neutron-ovs-cleanup start wait... 2) service neutron-ovs-cleanup status && echo OK should say active(exited) then OK at the end. 3) service neutron-ovs-cleanup stop 4) service neutron-ovs-cleanup status should say (inactive) dead Repeat for neutron-netns-cleanup If this doesn't work, step 2 will fail.
Created attachment 946777 [details] RemainAfterExit enabled for oneshot systemd services.
Hmmm, I believe now that it won't work for pacemaker, as pacemaker expects that cleanup happens at "start" and also at "stop" time. neutron-agents-pre (cleanup) are depended by other agents, that makes the -pre to "start" before any agents, and "stop" when all other agents are gone, thus cleaning up (could be wrong here, but the mechanism is +/- this). So this change wouldn't help to get rid of the OCF resources which actually implement this.
Fabio, am I right with comment 6?
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
(In reply to Miguel Angel Ajo from comment #7) > Fabio, am I right with comment 6? Yes you are correct.
Hmmm, I found that this idea works, if we replicate the ExecStart= field of the service definition with an ExecStop= I tried this before, but without the RemainAfterExit= So, it's possible to use it. Sorry for the noise.
needinfo asking for qa_ack+
I honestly have no strong opinion on the technical solution (systemd or pacemaker) but since it's working already as-is, while saving a few lines of code is nice, it means propagating lots of change between pacemaker config and puppet that might not be worth at all switching at this stage. Just 2c.
(In reply to Fabio Massimo Di Nitto from comment #12) > I honestly have no strong opinion on the technical solution (systemd or > pacemaker) but since it's working already as-is, while saving a few lines of > code is nice, it means propagating lots of change between pacemaker config > and puppet that might not be worth at all switching at this stage. > > Just 2c. Thanks Fabio, Looking on the deployment side of things I believe you're right and I agree with you, as we'd bounce deployments back eventually, and I'm not sure how well will puppet scripts handle a change from the OCF resources to the systemd ones. We ease maintenance, but could be risking already existing deployments, at least that'd require specific QA testing during upgrades. As it's a tiny change to the already existing .service files, I'd go on with it, and make it readily available on the packages without bouncing back deployment side unless we find a strong reason to do anytime later. We ship already the service files, and those are used in normal deployments too, so we may maintain those, and could eventually help.
I agree that there is no strong push to replace OCF resources right now, and it's still ok to have those service files updated in case we change our mind in the future.
Created attachment 947832 [details] RemainAfterExit oneshot systemd scripts fix.
I wonder whether we even want to have it outside of Delorean (RDO master). Is there any forseable use case for the change? If not, probably it's better to stay conservative with the change and avoid it in RHEL-OSP until Kilo when we get the patch from RDO.
Miguel - can you check this is available in delorean, if so let's close this bug as we can live without it in rhel-osp.
I don't foresee any need for it, since the OCF resource could do the same job. So I guess we are good until Kilo?. I will close it for now, but we can re-open if we find a good use or another good reason.