Bug 1147153

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.