[Nut-upsuser] On retiring some terminology

[Jim Klimov]

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