<!DOCTYPE html>
<html><head>
<meta charset="UTF-8">
</head><body><p>Hello everybody</p><p><br></p><p>This is my first post on this mailing list and I am only using Pacemaker since fall 2015 ... please be gentle :-) and I will do the same.</p><p><br></p><p>Our cluster is using multiple resource agents that update various node attributes (via RAs like sysinfo, healthcpu, etc.) in the form of #health.* and we rely on the mechanism enabled via the property node-health-strategy=migrate-on-red to trigger resource migrations.<br></p><p>In Pacemaker version 1.1.12 crm_mon -A or -XA would still display these #health.* attributes, but not since we have moved up to 1.1.14 and I am not sure why this needed to be changed :<br><br><span style="font-family: 'andale mono', monospace;">root@ys0-resiliency-test-1:~# crm node status-attr pg1 show \#health-cpu </span><br><span style="font-family: 'andale mono', monospace;"><strong>scope=status name=#health-cpu value=green</strong></span></p><p><span style="font-family: 'andale mono', monospace;">root@ys0-resiliency-test-1:~# crm_mon -XrRAf1 | grep -i '#health' ; echo $? </span><br><span style="font-family: 'andale mono', monospace;"><strong>1</strong></span></p><p><strong><br></strong></p><p>This seems to be due to this part of the crm_mon.c code:</p><p><span style="font-family: 'andale mono', monospace;">/* Never display node attributes whose name starts with one of these prefixes */</span><br><span style="font-family: 'andale mono', monospace;">#define FILTER_STR { "shutdown", "terminate", "standby", "fail-count", \</span><br><span style="font-family: 'andale mono', monospace;">                                    "last-failure", "probe_complete", <strong>“#”</strong>, NULL }</span></p><p><strong><br></strong></p><p>I would like to know if anybody is sharing my opinions on that:<br></p><p>   1. From an operations point of view it would be easier to get crm_mon to include #health.* in the general output or at least in the XML output via crm_mon -XA, so that I can get a comprehensive status view in one shot.<br></p><p>   2. Because the node attributes list can be extensive and clutters up the output it would make sense to allow a user-defined filter for node attributes in general</p><p><br></p><p>Regards,</p><p>Martin Schlegel</p></body></html>