[Nut-upsuser] On retiring some terminology

[Jim Klimov]

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)
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20210314/2683ec82/attachment-0001.htm>