[Nut-upsdev] Joining forces with the Network UPS Tools

Arnaud Quette aquette.dev at gmail.com
Mon Oct 20 13:46:24 UTC 2008


2008/10/6 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Arnaud Quette <aquette.dev at gmail.com>:
>
>>> Never mind, I already figured out a usage. If one of the machines
>>> connected
>>> to an outlet gets stuck and you want to cycle the power on that outlet
>>> (probably the main reason to use RPC's in the first place) you want to
>>> bring
>>> down the other systems on that outlet down cleanly. Shutting down the
>>> whole
>>> UPS/RPC system is currently the only option and this could be made more
>>> fine
>>> grained.
>>
>> that's 1 of the 2 main use cases here.
>> the other being that upsmon could monitor
>> outlet.X.autoswitch.charge.low (where X is the outlet on which we
>> subscribed the slave) against battery.charge to launch the shutdown
>> without the need of upssched.
>
> I'm afraid that's something that is not very practical to use. :-)

well, for the user, it simply means a small addon in upsmon.conf, like:
MONITOR system powervalue username password type
with system being currently:
<upsname>[@<hostname>[:<port>]]
transformed into:
<upsname>[[:outlet-number]@<hostname>[:<port>]]

the thing is that, for that particular purpose (outlet subscription),
we need to handle this smartly.
we don't only want to shutdown early. But also to handle associated
commands (off / reboot of an outlet) smartly.
ie, the smart loads have to be instructed that they have to shutdown.
the reboot is an extension of this case, with a sufficient delay for
the load to shutdown. The on part is then standard...

but I have to shake a bit more that idea before things get clear...

> We would need to know in advance then how much time is remaining before the
> UPS reaches the 'autoswitch' level. Any mistakes here, and you risk that the
> UPS will switch off the power before the client has finished shutting down.
> As far as I'm concerned, the only use for 'outlet.X.autoswitch.charge.low'
> is for loads that don't suffer from a sudden power loss. I don't think many
> systems running 'upsmon' fall into that category.
>
> Regarding the use of multiple outlet systems, this could be solved in a
> driver independent way by creating a 'repeater' driver. That driver would
> connect to an existing driver socket and provide additional 'pseudo' UPS'es
> with an additional command set that tells which parameters to override from
> the master UPS:
>
> [master-ups]
>   driver = usbhid-ups
>   port = auto
>
> [slave-1]
>   driver = repeater
>   port = master-ups
>   desc = "Outlet 1"
>   battery.charge.low = 30
>   [...]
>
> [slave-2]
>   driver = repeater
>   port = master-ups
>   desc = "Outlet 2"
>   battery.charge.low = 50

you mean "override.battery.charge.low = 50" ;-)
otherwise, we'll have to give makevartable the whole list of nut variables...

>   [...]
>
> You get the idea. The repeater would just listen to the master and adjust
> the 'ups.status' and 'battery.charge.low' (in this example) accordingly.
>
> The advantage here is that we don't need any changes to the existing server
> or clients. It also doesn't need any changes to existing drivers, since they
> already support multiple connections on their driver socket.

interesting. don't know you if you recall, but I once talked about a
similar approach for the composite devices (paralell/serialized UPSs,
chained UPS and PDUs, ...) to operate some data processing.

As told at the beginning of the mail, your approach fails in this
particular case because there is no link between the real ups
(master-ups) and the sub ones. So, what happens if you fire an
outlet.1.load.off on the master?

while we're at this, dummy-ups is a serious candidate for this job!

I still have to think a bit more about all these (linked) subjects.
but as always, comments / feedback welcome. This helps a lot in
clarifying things.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/



More information about the Nut-upsdev mailing list