<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>11 post over the last year on this topic. Lots of effort
expended on a WOKE problem far more than effort expended on real
issues that actually affect code functionality. My condolences.</p>
<p>BIND went through this a few years ago also. There seems to be
one or two actors in the OSS community who have created no code
themselves other than taking this master/slave terminology issue
and trying to guilt people over it. Ah well I guess if it makes
white people happy to virtue signal instead of just quietly
changing the documentation and shutting up about it then we have
accomplished something, eh?</p>
<p><eyeroll><br>
</p>
<p>Ted<br>
</p>
<div class="moz-cite-prefix">On 3/12/2022 2:22 AM, Jim Klimov via
Nut-upsdev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJYg8vKFMfEqHS-zqpEBtNuj1E7N=ZY5kyCZwgyPhrpj3Fj8Zw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">On a side note, new configuration file keywords
added in earlier PRs, and to a lesser extent this protocol
change (should not be disruptive for old/new server/client
chatter), prompted the anticipated next NUT release to be semver
bumped to 2.8.x (x=0).</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022, 19:39
Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com"
moz-do-not-send="true">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="auto">FYI: PR <a
href="https://github.com/networkupstools/nut/pull/1328"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">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" target="_blank"
rel="noreferrer" moz-do-not-send="true">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"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/networkupstools/nut/pull/989</a></div>
<div>* <a
href="https://github.com/networkupstools/nut/pull/990"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/networkupstools/nut/pull/990</a></div>
<div>* <a
href="https://github.com/networkupstools/nut/pull/991"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Nut-upsdev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nut-upsdev@alioth-lists.debian.net">Nut-upsdev@alioth-lists.debian.net</a>
<a class="moz-txt-link-freetext" href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
</pre>
</blockquote>
</body>
</html>