> On 5 Dec 2015, at 4:22 AM, Ken Gaillot <kgail...@redhat.com> wrote: > > On 12/04/2015 10:59 AM, Jan Pokorný wrote: >> Btw. was any other architectural approach considered? It's sad >> that multiplatform IPC, which is what might be better to handle >> more or less continuous one-way stream of updates
but requires us to build in knowledge of, and a library dependancy on, every possible target. we’ve already seen how well that went for just SNMP and SMTP, let alone whatever current management fad has captured people’s attention. by contrast, there is always a CLI tool >> (would the exec >> mechanism apply some kind of rate-limiting to prevent exhaustion?), >> but what about > > There is no rate limiting on the Pacemaker end. If there winds up > being a big demand for it, we can look into it, but that is more > likely to be useful within the script itself (a script that notifies > another service of status changes likely does not want rate limiting, > but an SMS notifier sure might). agreed. this belongs in the scripts or some intermediate party. also, by definition, the notification overhead is less than that of the resources they are for. so the node itself should be ok, the person on the other end… that is why people install alert management systems. > >> long-lived unix sockets or named pipes? Especially the latter >> might be doable in the agent just in shell + coreutils and other >> basic tooling and might play well with file discovery approach. > > Simple shell scripts are often the limit of sysadmins' abilities in > this area, so the less they have to know/do the better. > > _______________________________________________ > Developers mailing list > Developers@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
