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.
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?
<eyeroll>
Ted
On 3/12/2022 2:22 AM, Jim Klimov via Nut-upsdev wrote:
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).
On Fri, Mar 11, 2022, 19:39 Jim Klimov <[email protected]
<mailto:jimklimov%[email protected]>> wrote:
FYI: PR https://github.com/networkupstools/nut/pull/1328 adds
handling of `PRIMARY` alias to `MASTER` on protocol side,
hopefully completing the puzzle for issue #840.
Reviews and testing would be welcome :)
On Sun, Mar 14, 2021, 00:34 Jim Klimov <[email protected]
<mailto:jimklimov%[email protected]>> wrote:
Thanks again for all the suggestions.
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.
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 :)
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):
* https://www.surveymonkey.com/r/GBHQM7Q
Changes related to upsmon, and bookmarks for protocol "MASTER"
keyword, are PRed here:
* https://github.com/networkupstools/nut/pull/992
Also some nearby paragraphs in the docs were updated and
extended, which I extracted into separate PRs - reviews welcome:
* https://github.com/networkupstools/nut/pull/989
* https://github.com/networkupstools/nut/pull/990
* https://github.com/networkupstools/nut/pull/991
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? :)
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.
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.
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).
Thanks all,
Jim Klimov
On Sat, Mar 13, 2021 at 1:02 PM Stuart Henderson
<[email protected]> wrote:
In gmane.comp.monitoring.nut.devel, you wrote:
> I looked around for suitable synonyms, and for our
primary use-case with
> upsmon roles - where it either manages an UPS by direct
link and tells
> others to shut down ASAP, or is one of such shutdown
agents being told what
> to do, words "manager" and "subordinate" seem neutral
enough and reflective
> of the activities and relationship of these actors.
Hi Jim. I think "agent" would likely work better than
"subordinate".
"manager" is not perfect but seems ok and I can't think of
anything better
(could also be "controller" but I think that's just
different rather than
necessarily better!)
Thanks,
Stuart (OpenBSD porter)
>
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
