[Nut-upsdev] Questions about failover architecture

[Sebastian Kuttnig]

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>