>I also remember something about racing with dnsmasq, at which point I'd<div id="yMail_cursorElementTracker_1616877170876">say that making cluster depend on availability of DNS is e-h-h-h unwise</div><div id="yMail_cursorElementTracker_1616877192539"><br></div><div id="yMail_cursorElementTracker_1616877192756"><br></div><div id="yMail_cursorElementTracker_1616877192974">Not my choice... Or at least I would deploy bind/unbound caching servers in the same VLAN instead of dnsmasq.</div><div id="yMail_cursorElementTracker_1616877234198">Also, Filesystem resource agent's read + write check is quite usefull. We got a crazy clusterized environment where on several occasions read-only FS did not cause a  failover (it's not pacemaker) and I prefer to not be awaken by the oncall when this happens with the Scale-out I'm building (currently it's just the QA cluster, but soon coming the prod).</div><div id="yMail_cursorElementTracker_1616877359991"><br></div><div id="yMail_cursorElementTracker_1616877360159">The bad thing is this one is the first pacemaker in the environment and I need to make it completely 'killer' or I will be forced to use the old cluster solution which is crap (due to the implementation , not due to the product).</div><div id="yMail_cursorElementTracker_1616877441726">... double fencing mechanisms, fencing when FS is dead or HANA is having troubles, etc.</div><div id="yMail_cursorElementTracker_1616877566986"><br></div><div id="yMail_cursorElementTracker_1616877567217"><br></div><div id="yMail_cursorElementTracker_1616877580187"><br></div><div id="yMail_cursorElementTracker_1616877580379">Anyway, I am hoping that such kind of constraints will be more easier to implement in the future, as this one is quite complex and it will give me a hard time to explain it to the  colleagues.</div><div id="yMail_cursorElementTracker_1616877647725"><br></div><div id="yMail_cursorElementTracker_1616877567417">Best Regards,</div><div id="yMail_cursorElementTracker_1616877572057">Strahil Nikolov</div>