8) On Xenial and on, where we have systemd .service files for both corosync and pacemaker, this is my current understanding (after looking at the .service files and thinking about the Trusty case, as well; some of this is repeats of others' observations):
8a) corosync can be installed configured without pacemaker, so there is no direct reverse-dependency on pacemaker for corosync. 8b) pacemaker.service already is After= and Requires= corosync.service. This makes me less interested in the heartbeat case for 16.04+, as that would imply administrator customization (afaict). 8c) The above stanza elements only ensure that when pacemaker.service is started, that it is after corosync.service (After=) and ensures corosync.service is running (Requires=). There is no expression that would currently assert that corosync.service should start pacemaker.service (and as mentioned in 8a, as well as based upon Trusty, that would be incorrect). 9) It seems like what we want to express for systemd is that when corosync.service is restarted, that pacemaker.service is restarted, if it was running before; similar to the proposed Trusty change. I believe PartOf would achieve this correctly, as stops are safe to propogate from corosync to pacemaker as the systemd unit files by default have the Requires= dependency already. 10) invoke-rc.d is the means by which both Trusty and Xenial+ end up stopping corosync.service (prerm) and starting it (postinst) in the maintscripts. xnox is right, I believe, that if the scripts were updated to restart corosync.service on upgrade, rather than manually stopping and starting them, this would be solved in coordination the PartOf= change. However, if that is not doable in the SRU, then it might make sense to check the status of pacemakerd in the prerm (before we stop corosync) and ensure it is back in that state in the postinst (after we start corosync). 11) I think the correct thing to do for Xenial is set PartOf in the pacemaker service file. 12) For both Trusty and Xenial (the actual change may be different), we want to ensure the corosync postinst correctly restores the state of pacemaker regardless of the init system in place. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1740892 Title: corosync upgrade on 2018-01-02 caused pacemaker to fail To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1740892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
