[Sending this as a separate mail, since the last one was already (too) long and focused on specific details, whereas this one takes a step back to think about the bigger picture again.]
Adam Spiers <[email protected]> wrote: > > >>>> On 09/21/2016 03:25 PM, Adam Spiers wrote: > > >>>>> As a result I have been thinking about the idea of changing the > > >>>>> start/stop/status actions of these RAs so that they wrap around > > >>>>> service(8) (which would be even more portable across distros than > > >>>>> systemctl). [snipped discussion of OCF wrapper RA idea] > The fact that I don't see any problems where you apparently do makes > me deeply suspicious of my own understanding ;-) Please tell me what > I'm missing. [snipped] To clarify: I am not religiously defending this "wrapper OCF RA" idea of mine to the death. It certainly sounds like it's not as clean as I originally thought. But I'm still struggling to see any dealbreaker. OTOH, I'm totally open to better ideas. For example, could Pacemaker be extended to allow hybrid resources, where some actions (such as start, stop, status) are handled by (say) the systemd backend, and other actions (such as monitor) are handled by (say) the OCF backend? Then we could cleanly rely on dbus for collaborating with systemd, whilst adding arbitrarily complex monitoring via OCF RAs. That would have several advantages: 1. Get rid of grotesque layering violations and maintenance boundaries where the OCF RA duplicates knowledge of all kinds of things which are distribution-specific, e.g.: https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/apache#L56 2. Drastically simplify OCF RAs by delegating start/stop/status etc. to systemd, thereby increasing readability and reducing maintenance burden. 3. OCF RAs are more likely to work out of the box with any distro, or at least require less work to get working. 4. Services behave more similarly regardless of whether managed by Pacemaker or the standard pid 1 service manager. For example, they will always use the same pidfile, run as the same user, in the right cgroup, be invoked with the same arguments etc. 5. Pacemaker can still monitor services accurately at the application-level, rather than just relying on naive pid-level monitoring. Or is this a terrible idea? ;-) _______________________________________________ Developers mailing list [email protected] http://clusterlabs.org/mailman/listinfo/developers
