[ClusterLabs Developers] RA as a systemd wrapper -- the right way?

[Jan Pokorný]

On 02/12/17 21:00 +0100, Jan Pokorný wrote:
> https://jdebp.eu/FGA/unix-daemon-readiness-protocol-problems.html
> 
> Quoting it:
>   Of course, only the service program itself can determine exactly
>   when this point [of being ready, that, "is about to enter its main
>   request processing loop"] is.
> 
> There's no way around this.
> 
> The whole objective of OCF standard looks retrospectively pretty
> sidetracked through this lense: instead of pulling weight of the
> semiformal standardization body (comprising significant industry
> players[*]) to raise awareness of this solvable reliability
> discrepancy, possibly contributing to generally acknowledged,
> resource manager agnostic solution (that could be inherited the
> next generation of the init systems), it just put a little bit of
> systemic approach to configuration management and monitoring on
> top of the legacy of organically grown "good enough" initscripts,
> clearly (because of inherent raciness and whatnot) not very suitable
> for the act of supervision nor for any sort of reactive balancing
> to satisfy the requirements (crucial in HA, polling interval-based
> approach leads to losing trailing nines needlessly for cases you
> can be notified about directly).

... although there was clearly a notion of employing asynchronous
mechanisms (one can infer, for technically more sound binding between
the resource manager and the supervised processes) even some 14+ years
ago:
https://github.com/ClusterLabs/OCF-spec/commit/2331bb8d3624a2697afaf3429cec1f47d19251f5#diff-316ade5241704833815c8fa2c2b71d4dR422

> Basically, that page also provides an overview of the existing
> "formalized intefaces" I had in mind above, in its "Several
> incompatible protocols with low adoption" section, including
> the mentioned sd_notify way of doing that in systemd realms
> (and its criticism just as well).
> 
> Apparently, this is a recurring topic because to this day, the problem
> hasn't been overcome in generic enough way, see NetBSD, as another
> example:
> https://mail-index.netbsd.org/tech-userlevel/2014/01/28/msg008401.html
> 
> This situation, caused by a lack of interest to get things right
> in the past plus OS ecosystem segmentation playing against any
> conceivable attempt to unify on a portable solution, is pretty
> unsettling :-/
> 
> [*] see https://en.wikipedia.org/wiki/Open_Cluster_Framework

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20171205/575c06a6/attachment-0004.sig>