Sebastian Kuttnig
2025-May-12 14:02 UTC
[Nut-upsdev] Questions about failover architecture
Hello Jim, I am following the direction of the `clone` drivers, although using the modern `upsdrvquery.c` API. Essentially I am parsing the protocol lines directly reading from the driver sockets, as the clone drivers do. As for ups.conf, I start up as follows without problems: [ups] driver = dummy-ups port = /etc/nut/5E.dev [ups2] driver = dummy-ups port = /etc/nut/APC.dev [failover] driver = failover port = dummy-ups-ups,dummy-ups-ups2 Is this what you had in mind? Appreciate any pointers regarding the `upsdrvctl` and `nutshutdown` specifics. Sebastian Am Mo., 12. Mai 2025 um 15:53 Uhr schrieb Jim Klimov < jimklimov+nut at gmail.com>:> Sounds great, thanks for the update! > > For communications with the other drivers (from failover or multiplexor), > I suggest using the local driver socket line the clone* drivers do: this > removes a dependency on `upsd` both for the service startup (no > chicken-and-egg issue of drivers before upsd, but upsd before the failover > driver) and for FSD end-game (after all services stopped, we just need to > start the drivers to talk to the UPS, no need for upsd so they can see each > other). > > Speaking of the latter, the `nutshutdown` script (or `upsdrvctl`) may need > an update to know to start those additional drivers. Or perhaps do them one > by one in case of shutdown command specifically (or any command generally), > until one succeeds. > > Jim > > > On Mon, May 12, 2025 at 3:22?PM Sebastian Kuttnig via Nut-upsdev < > nut-upsdev at alioth-lists.debian.net> wrote: > >> Hello again, >> >> I can report back that my failover driver is progressing nicely, and a >> lot of >> things seem to overlap with what could very well also be useful and maybe >> used >> eventually for a future multiplexing driver. >> >> Basically, my failover logic takes driver names (sockets) in >> comma-separated >> form from the `port` variable and keeps track of these drivers, monitoring >> their information and failing over where necessary. Basic configuration >> looks >> like: >> >> [failover] >> driver = failover >> port = dummy-ups-ups,dummy-ups-ups2 >> >> I could well picture a multiplexing driver accepting a similar format, >> merging >> variables of both drivers and resolving conflicts by port argument order >> (`dummy-ups-ups`, then `dummy-ups-ups2`) in its most basic form. >> >> Additionally, this could be extended with preference arguments, such as: >> >> prefer.ups.status = dummy-ups-ups >> prefer.battery.voltage.nominal = dummy-ups-ups2 >> >> Such definitions would take precedence over the port argument order, for >> more >> granular control. This could be similar to what is used in `ups.conf` for >> `default.<variable>` or `override.<variable>`, format-wise. >> >> If either driver were to drop offline, the other driver could take over >> with >> its full set of variables, regardless of other set preferences. >> >> Just a rough sketch of what I have in my mind. Time permitting, I'll start >> working on this at some point after I finish my failover explorations. >> >> Sebastian >> >> Am Mo., 12. Mai 2025 um 14:16 Uhr schrieb Greg Troxel via Nut-upsdev < >> nut-upsdev at alioth-lists.debian.net>: >> >>> Wow, that's quite the tale! >>> >>> I take away from this: >>> >>> There is a real example of wanting to merge two information sources. >>> >>> It's very complicated. >>> >>> Anybody wishing to succeed in a very complicated situation needs to >>> really pay attention, to twice as many things as they thought when >>> they started. >>> >>> It's unclear how to generalize from this to a solution that will work >>> for the next person. >>> >>> but if someone wants to write soemthing that is an aggregating driver >>> (looks like a driver, talks to N driver), and do so in a way that >>> doesn't cause any significant pain for others that seems like a fine >>> thing for them to do. >>> >>> I would suggest having some sort of config file that for each variable >>> says which driver to prefer, and some kind of timeout for not available >>> to flip to the backup. I guess for starters, one could configure two >>> drivers in "fancier/less-reliable" and "old-school" slots, and prefer >>> fancier for all except shutdown and status. >>> >>> I fear that the next layer is merging status from two where they don't >>> quite match. >>> >>> >>> >>> _______________________________________________ >>> Nut-upsdev mailing list >>> Nut-upsdev at alioth-lists.debian.net >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>> >> _______________________________________________ >> 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/20250512/b8dfdef5/attachment-0001.htm>
Sebastian Kuttnig
2025-May-12 15:24 UTC
[Nut-upsdev] Questions about failover architecture
P.S. To articulate better what I am unclear about from your message: `nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`.>From my understanding, this would command - all - `ups.conf` UPS toshutdown. So this would already include the UPS monitored by any failover/multiplexing driver. In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively. What kind of specific orchestration would be required for the "proxying" driver? My initial understanding was it would simply not support a shutdown command itself and `upsdrvctl` would command all supporting UPS to shutdown/start regardless of it. So similar to the clone* drivers, which seem not to have any special handling there. Thanks for the detailed responses so far, I am still exploring some areas of the NUT ecosystem. :-) Sebastian Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig < sebastian.kuttnig at gmail.com>:> Hello Jim, > > I am following the direction of the `clone` drivers, although using the > modern `upsdrvquery.c` API. > Essentially I am parsing the protocol lines directly reading from the > driver sockets, as the clone drivers do. > > As for ups.conf, I start up as follows without problems: > > [ups] > driver = dummy-ups > port = /etc/nut/5E.dev > > [ups2] > driver = dummy-ups > port = /etc/nut/APC.dev > > [failover] > driver = failover > port = dummy-ups-ups,dummy-ups-ups2 > > Is this what you had in mind? > Appreciate any pointers regarding the `upsdrvctl` and `nutshutdown` > specifics. > > Sebastian > > Am Mo., 12. Mai 2025 um 15:53 Uhr schrieb Jim Klimov < > jimklimov+nut at gmail.com>: > >> Sounds great, thanks for the update! >> >> For communications with the other drivers (from failover or multiplexor), >> I suggest using the local driver socket line the clone* drivers do: this >> removes a dependency on `upsd` both for the service startup (no >> chicken-and-egg issue of drivers before upsd, but upsd before the failover >> driver) and for FSD end-game (after all services stopped, we just need to >> start the drivers to talk to the UPS, no need for upsd so they can see each >> other). >> >> Speaking of the latter, the `nutshutdown` script (or `upsdrvctl`) may >> need an update to know to start those additional drivers. Or perhaps do >> them one by one in case of shutdown command specifically (or any command >> generally), until one succeeds. >> >> Jim >> >> >> On Mon, May 12, 2025 at 3:22?PM Sebastian Kuttnig via Nut-upsdev < >> nut-upsdev at alioth-lists.debian.net> wrote: >> >>> Hello again, >>> >>> I can report back that my failover driver is progressing nicely, and a >>> lot of >>> things seem to overlap with what could very well also be useful and >>> maybe used >>> eventually for a future multiplexing driver. >>> >>> Basically, my failover logic takes driver names (sockets) in >>> comma-separated >>> form from the `port` variable and keeps track of these drivers, >>> monitoring >>> their information and failing over where necessary. Basic configuration >>> looks >>> like: >>> >>> [failover] >>> driver = failover >>> port = dummy-ups-ups,dummy-ups-ups2 >>> >>> I could well picture a multiplexing driver accepting a similar format, >>> merging >>> variables of both drivers and resolving conflicts by port argument order >>> (`dummy-ups-ups`, then `dummy-ups-ups2`) in its most basic form. >>> >>> Additionally, this could be extended with preference arguments, such as: >>> >>> prefer.ups.status = dummy-ups-ups >>> prefer.battery.voltage.nominal = dummy-ups-ups2 >>> >>> Such definitions would take precedence over the port argument order, for >>> more >>> granular control. This could be similar to what is used in `ups.conf` for >>> `default.<variable>` or `override.<variable>`, format-wise. >>> >>> If either driver were to drop offline, the other driver could take over >>> with >>> its full set of variables, regardless of other set preferences. >>> >>> Just a rough sketch of what I have in my mind. Time permitting, I'll >>> start >>> working on this at some point after I finish my failover explorations. >>> >>> Sebastian >>> >>> Am Mo., 12. Mai 2025 um 14:16 Uhr schrieb Greg Troxel via Nut-upsdev < >>> nut-upsdev at alioth-lists.debian.net>: >>> >>>> Wow, that's quite the tale! >>>> >>>> I take away from this: >>>> >>>> There is a real example of wanting to merge two information sources. >>>> >>>> It's very complicated. >>>> >>>> Anybody wishing to succeed in a very complicated situation needs to >>>> really pay attention, to twice as many things as they thought when >>>> they started. >>>> >>>> It's unclear how to generalize from this to a solution that will work >>>> for the next person. >>>> >>>> but if someone wants to write soemthing that is an aggregating driver >>>> (looks like a driver, talks to N driver), and do so in a way that >>>> doesn't cause any significant pain for others that seems like a fine >>>> thing for them to do. >>>> >>>> I would suggest having some sort of config file that for each variable >>>> says which driver to prefer, and some kind of timeout for not available >>>> to flip to the backup. I guess for starters, one could configure two >>>> drivers in "fancier/less-reliable" and "old-school" slots, and prefer >>>> fancier for all except shutdown and status. >>>> >>>> I fear that the next layer is merging status from two where they don't >>>> quite match. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nut-upsdev mailing list >>>> Nut-upsdev at alioth-lists.debian.net >>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>>> >>> _______________________________________________ >>> 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/20250512/3a16ca71/attachment.htm>