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+...@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+...@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 <s...@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-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser