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

[Arnaud Quette]

Hi Arjen and the lists,

2008/10/20 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Arnaud Quette <aquette.dev at gmail.com>:
>
>>>> 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>]]
>
> I understand, but still (in the context of NUT), you can't use an
> autoswitched outlet (that was my point). We need an advance warning to be
> able to shutdown clients and this is something that autoswitched outlets
> don't provide as far as I know.

I fully agree, and forgot to comment that specific point.
the autoswitch is a special case, but I expect in the future to see
outlets working in the same mode than UPS (for the status and manual
off)
at the very least, we can emulate this, even with autoswitch.

btw, I will have soon another interesting case of outlet usage. can't
say more ATM...

finally, I'm thinking about making some helpers functions and
structures to make outlet integration and management easier.

>> 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.
>
> Understood. Still I think we should either handle this in either the driver
> or maybe even the server. The latter could also add additional devices if it
> noticed that a system has multiple outlets and the provide
>
>    upsname (default)
>    upsname-0
>    upsname-1
>    upsname-2
>
> for the various outlets. Basically the same idea as the chained approach,
> but with lower load on the driver (although I'm not too worried about that).

yeah, I really prefer the latter approach, as it is more global.

would you take over this implementation (upsd layer).
note that I've a patch underway to fix the outlet naming:
outlet.0 is renamed to outlet (ie outlet.voltage instead of
outlet.0.voltage...), as per the original spec.
so, the enum starts for .1

the only thing remaining is the var mapping...

>> The on part is then standard...
>
> No, it isn't. That's the tricky part here. It could very well be that (when
> running on battery)  by switching off a substantial part of the load means
> the remaining runtime of a UPS goes up, higher than the switch-off point for
> that outlet. So you risk that the outputs will return then and the whole
> process starts again. Deciding when to switch on the loads is probably a lot
> more difficult than when to switch them off.

good catch, I've not checked that. have you tried it on your side?
I'll check and setup a testbed on monday to verify how it currently behave

> [...]
>
>> 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.
>
> Sure there is, the slaves would see (almost) all the data from the master.
> To them, it is like they have a dedicated UPS with just one switchable
> outlet.
>
>> So, what happens if you fire an outlet.1.load.off on the master?
>
> The power to the clients on outlet 1 will be killed immediately, as
> instructed. You get what you ask for, just like what happens if you send the
> master a 'load.off' command. Whatever we do can never protect against
> operator error.

right.

thanks,
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/