<div dir="ltr">Hi Honza,<div>Thanks for your reply. Please find the attached image below:</div><div><br></div><div><div><img src="cid:ii_kdse6imi0" alt="image.png" width="403" height="305" style="margin-right: 0px;"><br></div></div><div><br></div><div>Yes, I am talking about pacemaker alerts only.</div><div><br></div><div>Please find my suggestions/requirements below:</div><div><br></div><div><b>Booth:</b></div><div>1. Node5 booth-arbitrator should be able to give event when any of the booth node joins or leaves. booth-ip can be passed in event.</div><div>2. Event when booth-arbitrator is up successfully and has started monitoring the booth nodes.</div><div>2. Geo site booth should be able to give event when its booth peers joins/leaves. For example, Geo site1 gives an event when node5 booth-arbitrator joins/leaves OR site2 booth joins/leaves.
booth-ip can be passed in event.
</div><div>3. On ticket movements (revoke/grant), every booth node(Site1/2 and node5) should give events.</div><div><br></div><div>Note: pacemaker alerts works in a cluster. Since, arbitrator is a non-cluster node, not sure how exactly it will work there. But this is good to have feature.</div><div><br></div><div><b>Qnetd/Qdevice:</b></div><div>This is similar to above.</div><div>1. Node5 qnetd should be able to raise an event when any of the cluster node joins/leaves the quorum.</div><div>2. Event when qnetd is up successfully and has started monitoring the cluster nodes
</div><div>3. Cluster node should be able to give event when any of the quorum node leaves/joins.<br></div><div><br></div><div>If you see on high level, then these are kind of node/resource events wrt booth and qnetd/qdevice.</div><div><br></div><div>As of today wrt booth/qnetd, I don't see any provision where any of the nodes gives any event when its peer leaves/joins. This makes it difficult to know whether geo sites nodes can see booth-arbitrator or not. This is true the other way around also where booth-arbitrator cannot see geo booth sites. </div><div>I am not sure how others are doing it in today's deployment, but I see need of monitoring of every other booth/qnet node. So that on basis of event, appropriate alarms can be raised and action can be taken accordingly.</div><div><br></div><div>Please let me know if you agree on the usecases. I'll raise feature-request on the pacemaker upstream project accordingly.</div><div><br></div><div>Thanks,</div><div>Rohit</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 8:58 PM Jan Friesse <<a href="mailto:jfriesse@redhat.com">jfriesse@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rohit,<br>
<br>
Rohit Saini napsal(a):<br>
> Hi Team,<br>
> <br>
> Question-1:<br>
> Similar to pcs alerts, do we have something similar for qdevice/qnetd? This<br>
<br>
You mean pacemaker alerts right?<br>
<br>
> is to detect asynchronously if any of the member is unreachable/joined/left<br>
> and if that member is qdevice or qnetd.<br>
<br>
Nope but actually shouldn't be that hard to implement. What exactly <br>
would you like to see there?<br>
<br>
> <br>
> Question-2:<br>
> Same above question for booth nodes and arbitrator. Is there any way to<br>
> receive events from booth daemon?<br>
<br>
Not directly (again, shouldn't be that hard to implement). But pacemaker <br>
alerts should be triggered when service changes state because of ticket <br>
grant/reject, isn't it?<br>
<br>
> <br>
> My main objective is to see if these daemons give events related to<br>
> their internal state transitions and raise some alarms accordingly. For<br>
> example, boothd arbitrator is unreachable, ticket moved from x to y, etc.<br>
<br>
I don't think "boothd arbitrator is unreachable" alert is really doable. <br>
Ticket moved from x to y would be probably two alerts - 1. ticket <br>
rejected on X and 2. granted on Y.<br>
<br>
Would you mind to elaborate a bit more on events you would like to see <br>
and potentially open issue for upstream project (or, if you have a RH <br>
subscription try to contact GSS, so I get more time to work on this issue).<br>
<br>
Regards,<br>
Honza<br>
<br>
> <br>
> Thanks,<br>
> Rohit<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Manage your subscription:<br>
> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
> <br>
> ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
> <br>
<br>
</blockquote></div>