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>
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>
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>