[Nut-upsdev] On retiring some terminology

[Ted Mittelstaedt]

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 <jimklimov+nut at gmail.com 
> <mailto:jimklimov%2Bnut at gmail.com>> 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 <jimklimov+nut at gmail.com
>     <mailto:jimklimov%2Bnut at gmail.com>> 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
>         <stu at spacehopper.org> 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
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20220312/b3a3913c/attachment.htm>