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/20220311/a2d23e0d/attachment.htm>