Nut upsdev - Oct 2008 - Joining forces with the Network UPS Tools

Hi Powermen ;-)

I recently came across the Powerman project
(http://sourceforge.net/projects/powerman/), pointed by Tony Merenda,
from Opengear (thanks Tony). Congrats for your work in this area!

I've thought a bit about Powerman and NUT since then...

NUT currently supports hosts of UPSs and few PDUs (RPCs), and provides
tons of features:
http://test.networkupstools.org
http://test.networkupstools.org/Documentation/UserManual/Features
http://test.networkupstools.org/Documentation/UserManual/Compatibility/Stable

I'm currently preparing the support of 4 Eaton network (SNMP) PDUs
(the full Eaton range, from Aphel and Pulizzi)
This is based upon the outlet collection:
http://svn.debian.org/wsvn/nut/trunk/docs/new-names.txt?op=file&rev=0&sc=0
And will be as simple as creating a few .h files like that one:
http://svn.debian.org/wsvn/nut/trunk/drivers/mgemib.h?op=file&rev=0&sc=0

See also
http://svn.debian.org/wsvn/nut/trunk/docs/powersaving.txt?op=file&rev=0&sc=0
for some more info on the outlet data collection.

Although the name of the project implies UPS only, I'm willing to
expand NUT to any external power devices. NUT provide many generic
acquisition drivers for serial, USB, SNMP, XML/HTTP, that aren't hard
to be extended. There is even an APC MasterSwitch supported by the
generic serial driver.

So integrating Powerman devices, knowledges and expertize into the NUT
shouldn't be that hard, but would be a great deal for end users:
- RPCs would be available through the network, protected by user auth,
SSL and ACLs.
- GUIs would be easy to develop/adapt using the NUT protocol, the
Python class or the C/C++ client library
(imagine an RPC interactive picture...)
- We could manage a full power chain of UPSs and RPCs, and add some
smarter/advanced features (like subscribing clients (nut slaves
installed on computers) on a specific outlet, and have these shutdown
earlier than others before putting the outlet off)
- Powerman's features would be distributed with the NUT packages,
across a wide set of systems,
- a bigger team, with all that it implies
...

NUT would also have to be extended a bit, for example by adding a
field to determine the device type (ups or rpc/pdu), by modifying the
compatibility list format, ...

What would you think about all that. I'm opened to any questions and
remarks.

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/

Citeren Arnaud Quette <aquette.dev at gmail.com>:
> So integrating Powerman devices, knowledges and expertize into the NUT
> shouldn't be that hard, but would be a great deal for end users:
> - RPCs would be available through the network, protected by user auth,
> SSL and ACLs.
Minus the ACLs, we're dropping those in the next release.
> - GUIs would be easy to develop/adapt using the NUT protocol, the
> Python class or the C/C++ client library
> (imagine an RPC interactive picture...)
That would be neat.
> - We could manage a full power chain of UPSs and RPCs, and add some
> smarter/advanced features (like subscribing clients (nut slaves
> installed on computers) on a specific outlet, and have these shutdown
> earlier than others before putting the outlet off)
I'm not sure what you're trying to accomplish here. Why would clients  
subscribe to a specific outlet? And why would we want to switch off an  
outlet early?

We already have 'upssched' to shutdown clients early, so the only load  
saving that would benefit from shutdown through the outlet switches  
are 'dumb' devices that don't run NUT client software or NUT clients
that somehow are no longer responsive. In both cases, they will be  
shutdown 'hard' anyway and as far as I can see there is little you can  
do about it.

Best regards, Arjen
-- 
Please keep list traffic on the list

Hi Arnaud,

Thanks for the inquiry and for bringing NUT to my attention.
I think I actually looked at it a long time ago under another name.
Looks like it has come a long way and matured a lot since then.  Nice job!

I'm keen to keep powerman simple with a small set of features,
in the "do one thing and do it well" tradition of UNIX tools.
I also want to retain it as a standalone package.  However, lets 
definitely think about how to leverage each others work to improve
both projects.

Would it make any sense for us to interface NUT with the powerman daemon
and push all the power controller support behind powerman?   Sort of a
componentized approach?  I would need to add SNMP support to cover what 
you have now.  Powerman has "native" serial, TCP/telnet, and coprocess
support
now.  We add on IPMI, HTTP, GPIB, VXI-11, and Insteon via the coprocess 
interface (for example see src/httppower.c in the powerman sources).
This is where the powerman daemon spawns another process and controls its
stdin/stdout via pty.  I think SNMP could also be done via the coprocess
approach.  

Another area where we might share is in test suites.  Powerman includes
simple stdin/stdout simulators of several power controller CLI's.  When
I run "make check" in the powerman source tree, it spins through a
bunch
of these, running them as coprocesses, exercising various commands to be
sure I haven't broken anything.  If we both supported the same hardware, 
perhaps we could share these simulators?  Even potentially add support for
hardware in both projects that only one of us has access to?

I'll have a closer look at NUT and see what else comes to mind.

Regards,

Jim Garlick

On Sat, Oct 04, 2008 at 10:59:41PM +0200, Arnaud Quette
wrote:
> Hi Powermen ;-)
> 
> I recently came across the Powerman project
> (http:// sourceforge.net/projects/powerman/), pointed by Tony Merenda,
> from Opengear (thanks Tony). Congrats for your work in this area!
> 
> I've thought a bit about Powerman and NUT since then...
> 
> NUT currently supports hosts of UPSs and few PDUs (RPCs), and provides
> tons of features:
> http:// test.networkupstools.org
> http:// test.networkupstools.org/Documentation/UserManual/Features
> http://
test.networkupstools.org/Documentation/UserManual/Compatibility/Stable
> 
> I'm currently preparing the support of 4 Eaton network (SNMP) PDUs
> (the full Eaton range, from Aphel and Pulizzi)
> This is based upon the outlet collection:
> http://
svn.debian.org/wsvn/nut/trunk/docs/new-names.txt?op=file&rev=0&sc=0
> And will be as simple as creating a few .h files like that one:
> http://
svn.debian.org/wsvn/nut/trunk/drivers/mgemib.h?op=file&rev=0&sc=0
> 
> See also http://
svn.debian.org/wsvn/nut/trunk/docs/powersaving.txt?op=file&rev=0&sc=0
> for some more info on the outlet data collection.
> 
> Although the name of the project implies UPS only, I'm willing to
> expand NUT to any external power devices. NUT provide many generic
> acquisition drivers for serial, USB, SNMP, XML/HTTP, that aren't hard
> to be extended. There is even an APC MasterSwitch supported by the
> generic serial driver.
> 
> So integrating Powerman devices, knowledges and expertize into the NUT
> shouldn't be that hard, but would be a great deal for end users:
> - RPCs would be available through the network, protected by user auth,
> SSL and ACLs.
> - GUIs would be easy to develop/adapt using the NUT protocol, the
> Python class or the C/C++ client library
> (imagine an RPC interactive picture...)
> - We could manage a full power chain of UPSs and RPCs, and add some
> smarter/advanced features (like subscribing clients (nut slaves
> installed on computers) on a specific outlet, and have these shutdown
> earlier than others before putting the outlet off)
> - Powerman's features would be distributed with the NUT packages,
> across a wide set of systems,
> - a bigger team, with all that it implies
> ..
> 
> NUT would also have to be extended a bit, for example by adding a
> field to determine the device type (ups or rpc/pdu), by modifying the
> compatibility list format, ...
> 
> What would you think about all that. I'm opened to any questions and
remarks.
> 
> 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/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http:// moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Powerman-discuss mailing list
> Powerman-discuss at lists.sourceforge.net
> https:// lists.sourceforge.net/lists/listinfo/powerman-discuss

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. :-)

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 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.

Best regards, Arjen
-- 
Please keep list traffic on the list