[ClusterLabs] About the pacemaker

[Jan Pokorný]

On 10/01/19 14:53 +0100, Jan Pokorný wrote:
> On 08/01/19 10:14 -0600, Ken Gaillot wrote:
>> On Tue, 2019-01-08 at 15:27 +0800, T. Ladd Omar wrote:
>>> I have a question, if the Pacemaker has an event-notify interface
>>> which is realized by push&pull. Recently I want to do something
>>> extra using other process when the resources being started or
>>> deleted. So I need a way to monitor the resources events.
>>> ClusterMon and alerts both use external-scripts for extra actions,
>>> but in my situation, the specific process might have not being
>>> started. I hope pacemaker itself could store the old events and
>>> flush them for updating until the specific process starts and
>>> subscribe to Pacemaker, then pull all the old events. Also the
>>> Pacemaker could push to it when new events come.
>> 
>> I would use alerts with alert_file.sh (with custom modifications if
>> desired) to record them to a file, then have your process look at that.
>> (Tip: if you only care about events since the last boot, put the file
>> in /run so you don't have to worry about cleaning it up.)
> 
> Based on what's been described, it sounds like asking for extended
> functionality that might be served with an external "store-and-forward"
> daemon.  Such a daemon would also alleviate the processing complexity
> in case of plentiful alert subscribers when they are used for subsequent
> forwarding and/or extraction to assist decisions, since it would
> conceptually detach such postprocessing from the main executive flow
> fully (e.g. no sharing of the same security boundaries, cgroup, etc.;
> access control would be the sole responsibility of this daemon),

perhaps also rate-limiting possibly using priorities, even

> and allow for durability of the events with desired parameters.  
> 
> Such a daemon could then gradually overtake the responsibility to
> keep event stream subscribers updated, itself making use of a more
> suitable hooking directly into pacemaker.
> 
> That's how the future could evolve.  Contributions welcome.

-- 
Nazdar,
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/users/attachments/20190110/69e879ec/attachment.sig>