<div dir="auto">FYI: PR <a href="https://github.com/networkupstools/nut/pull/1328">https://github.com/networkupstools/nut/pull/1328</a> adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840.<div dir="auto"><br></div><div dir="auto">Reviews and testing would be welcome :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 14, 2021, 00:34 Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks again for all the suggestions.</div><div><br></div><div>For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology.</div><div>Now that we know where to change it, should not be too great a hassle to replace
 again

 by some other choice... subordinate was a bit too long to type :)</div><div><br></div><div>To make the election of team choice more simple, I have prepared my first SurveyMonkey poll here - it should be possible to choose one response for each of the two roles (although if you really can't pick one of several names you like, you should be able to take the poll again):</div><div>* <a href="https://www.surveymonkey.com/r/GBHQM7Q" target="_blank" rel="noreferrer">https://www.surveymonkey.com/r/GBHQM7Q</a></div><div><br></div><div>Changes related to upsmon, and bookmarks for protocol "MASTER" keyword, are PRed here:<br></div><div>* <a href="https://github.com/networkupstools/nut/pull/992" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut/pull/992</a></div><div><br></div><div>Also some nearby paragraphs in the docs were updated and extended, which I extracted into separate PRs - reviews welcome:</div><div>
<div>* <a href="https://github.com/networkupstools/nut/pull/989" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut/pull/989</a></div>


<div>* <a href="https://github.com/networkupstools/nut/pull/990" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut/pull/990</a></div>


<div>* <a href="https://github.com/networkupstools/nut/pull/991" target="_blank" rel="noreferrer">https://github.com/networkupstools/nut/pull/991</a></div>

</div><div><br></div><div>Review of the sources and docs on upsmon also revealed an aspect I did not realize (or have long forgotten) that, at least as is documented in several spots, a shutdown of an upsmon in "master" mode - even if graceful for maintenance - should set the FSD flag and bring the larger server farm down, apparently for a reason but I can't think of one except that the farm might no longer know when to go down if power disappears and/or there is nobody to power-cycle the UPS. Otherwise it feels counter-productive, and I don't think I've seen that in practice though, have you? :)</div><div><br></div><div>On the opposite: the upsmon source code for "slave" mode (and docs for it) actually have support for an outage of the "master" -- if slaves see an "FSD" flag on the server (some drivers can set it too), or "OB+LB" state which does not disappear within a few seconds, they go on shutting down even if there is no "master" upsmon to set FSD.</div><div><br></div><div>And answering my earlier uncertainty, it is the "master"-mode upsmon that actively sets the FSD flag in the upsd state (and also some drivers can do so), not upsd which then indeed acts like a message broker.<br></div><div><br></div><div>Another note is that it seems that upsmon may run in master mode on a different system than that with upsd and drivers for that monitored UPS, though I can't think of good reasons why that can be useful, perhaps beyond same-box containers or chroots (at least, such "different system" is usually not wired to power-down or reset the UPS at the end of master upsmon's shutdown).</div><div><br></div><div>Thanks all,<br></div><div>Jim Klimov<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 13, 2021 at 1:02 PM Stuart Henderson <<a href="mailto:stu@spacehopper.org" target="_blank" rel="noreferrer">stu@spacehopper.org</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">In gmane.comp.monitoring.nut.devel, you wrote:<br>
>   I looked around for suitable synonyms, and for our primary use-case with<br>
> upsmon roles - where it either manages an UPS by direct link and tells<br>
> others to shut down ASAP, or is one of such shutdown agents being told what<br>
> to do, words "manager" and "subordinate" seem neutral enough and reflective<br>
> of the activities and relationship of these actors.<br>
<br>
Hi Jim. I think "agent" would likely work better than "subordinate".<br>
<br>
"manager" is not perfect but seems ok and I can't think of anything better<br>
(could also be "controller" but I think that's just different rather than<br>
necessarily better!)<br>
<br>
Thanks,<br>
Stuart (OpenBSD porter)<br>
><br>
</blockquote></div>
</blockquote></div>