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)
pgppERVlwhH_z.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers