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.
Sebastian Kuttnig
2025-May-12 13:21 UTC
[Nut-upsdev] Questions about failover architecture
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250512/497ed098/attachment.htm>