Arjen de Korte ha scritto:
Sure, but a single driver could contain all the (vendor) specific
logic without tainting the upsd code (starting from a netxml-ups clone
and my patch).
Your proposed changes to the netxml-ups driver
I have never proposed changes to the netxml-ups driver, I proposed to
include a simple NSM client in the mge-xml subdriver (single UPS
configuration only), OR a totally new NSM driver dealing with just
ALARMS and some other basic info (could easily poll data from many UPSes
and support the same redundancy configurations suported by the Eaton/MGE
software [1]). I simply asked for the better approach and inclusion
chances. That's all I said from the beginning.
I liked also the idea of having the netxml-ups and, let's say,
mgensm-ups drivers talking to each other side by side, but it looked too
complex/unfeasible (that's why I asked you about how to realize
communication).
That's all.
can only monitor a single UPS
That's how the Eaton NSM works: if multiple UPSes are involved you list
them, select the redundancy schema [2] and use a single virtual UPS as
"global sum" of the UPSes involved [3]. Obviously the "sum" must be
calculated accordingly to the schema (which is the difficult part) [4].
A possible sample configuration could be:
[globalups]
driver = mgensm-ups
port = parallel
minimum = 1
ups1.port = ups1.domain.com
ups1.outlet = main
ups2.port = ups2.domain.com
ups2.outlet = 2
...
As I said we assume that we are using only Eaton/MGE products, otherwise
the NSM does not look the way to go. About machines with multiple PSU,
if I'm not wrong NUT should already deal with them. Moreover you can use
multiple mgensm-ups instances (eg: virtualups1 -> PSU1 , virtualups2 ->
PSU2). I think that such a driver could complete NUT support for MGE
products. The downside of the separate driver is just a more complex
config in a single UPS-PSU scenario and the informations splitted into
two UPSes.
Not in the netxml-ups (or mge-xml subdriver). Given the above
difficulties, this *must* be a separate driver, because we already have
production systems that would break if this was added.
I can't see what would break but I'm for the separate driver too.
I would consider
a NSM driver only, but without the parsing of additional XML data from
the UPS. It should only parse the ALARM messages, nothing more. For
logging purposes, one would then have to run a SNMP or XML enabled
driver on the side and use the NSM one to shutdown attached clients.
And this is what I proposed since the beginning (however some other xml
informations have to be parsed once a while).
So, at the end, is it interesting or not? May I spend some time on this
in the future? Or am I going to waste my time?
Regards,
Marco
[1] http://i34.tinypic.com/2ynms9h.png
[2] http://i34.tinypic.com/2q04sbk.png
[3] http://i33.tinypic.com/xm3hg9.png
[4] http://i36.tinypic.com/vg07e9.png
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
