[Nut-upsdev] Questions about failover architecture

[Jim Klimov]

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/faddfd9f/attachment.htm>