In my opinion, from the list of desired properties, only the second one is true:
i) Corosync can be used on its own, regardless of having pacemaker installed or not. Starting both of them would force to mask pacemaker's unit file under particular scenarios.
iii) IIRC, pacemaker requires corosync to run, so this property can't happen (in fact pacemaker SIGTERMs its components when corosync is not available).
I like the idea stated at point 3) (restart on upgrade instead of stop+start). It would solve the issue without having to change the unit files.
Regarding Trusty, both corosync and pacemaker currently use sysV scripts. I ran a short test switching to upstart using the scripts in source [1] and it seems to work fine (thanks to the 'respawn' directive for pacemaker).
In my opinion, from the list of desired properties, only the second one is true:
i) Corosync can be used on its own, regardless of having pacemaker installed or not. Starting both of them would force to mask pacemaker's unit file under particular scenarios.
iii) IIRC, pacemaker requires corosync to run, so this property can't happen (in fact pacemaker SIGTERMs its components when corosync is not available).
I like the idea stated at point 3) (restart on upgrade instead of stop+start). It would solve the issue without having to change the unit files.
Regarding Trusty, both corosync and pacemaker currently use sysV scripts. I ran a short test switching to upstart using the scripts in source [1] and it seems to work fine (thanks to the 'respawn' directive for pacemaker).
[1] mcp/pacemaker. upstart. in init/corosync. conf.in
master/
master/