Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of alerts in qdevice and qnetd #13

Open
rohsaini opened this issue Aug 14, 2020 · 1 comment
Open

Support of alerts in qdevice and qnetd #13

rohsaini opened this issue Aug 14, 2020 · 1 comment

Comments

@rohsaini
Copy link

rohsaini commented Aug 14, 2020

I am requesting pacemaker alerts kind of feature for qdevice/qnetd. Please check the attached image.

  1. Node5 qnetd should be able to raise an event when any of the cluster node joins/leaves the quorum.
  2. qdevice node should be able to give event when any of the quorum node (i.e. qnetd or qdevice) leaves/joins.
  3. Event when qnetd is up successfully and has started monitoring the qdevice nodes

If you see on high level, then these are kind of node/resource events wrt qnetd/qdevice.

As of today wrt qdevice/qnetd, there is no provision where any of the nodes gives any event when its peer leaves/joins. This makes it difficult to know whether qdevice nodes can see qnetd or not. This is true the other way around also where qnetd cannot see qdevice nodes.
I am not sure how others are doing it in today's deployment, but I see need of monitoring of every other
qnet node. So that on basis of event, appropriate alarms can be raised and action can be taken accordingly.

image

@jfriesse
Copy link
Member

Relevant ML thread: https://lists.clusterlabs.org/pipermail/users/2020-August/027533.html

For Qnetd we may consider to add ability to call script/snmp/dbus event on important events, like qdevice client is connected/disconnected, partition got quorate.

Similarly for Qdevice we may add event when connected/disconnected to qnetd and change of vote. Change of quorate status is already handled by corosync.

Low prio tho, because implementation must be able to handle long running script, so calling of script must be asynchronous, and that's not super easy to implement with current architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants