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

Mon Oct 6 13:43:38 UTC 2008

Hi Jim,

2008/10/5 Jim Garlick <garlick at llnl.gov>:
> Hi Arnaud,
>
> Thanks for the inquiry and for bringing NUT to my attention.

and thanks a lot for your fast and constructive answer.

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

thanks for the team ;-)
smartupstools was the name before 2001.

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

that's also the case for NUT, though we have the need to secure that
sensitive area and handle from simple to complex setup with a good
bunch of much heterogeneous devices.

> I also want to retain it as a standalone package.

I see the point for a binary package (don't install features you don't
need), but less for the sources.
joining a mainstream project allows a better distribution...

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

I've already thought about that before.
The thing is that it adds another layer of complexity, where nut
already has 3 layers (driver, data server, clients).
The real interests of the merge is that:
- we can have all the data and smartness in a single point, while
putting all our efforts in the same project,
- users and integrators would only have 1 project to integrate, with
extensible features and tunability according to the needs,
- we can also play on the "flavoring" to distribute various oriented
binary packages (like what I did to address HAL), to only have the
equivalent of the current powerman installation (PDUs only, through
local connection).

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

that would rocks, knowing that QA is not our best point.
our distcheck target only covers the compilation of the full feature
set, but doesn't address the runtime portion. For that latter, I've
recently (~6 months ago) applied an automated testing suite using the
dummy-ups driver, and allowing to test the data propagation chain
(driver <-> upsd <-> client/upsmon)

the only point is that we have so many protocols and busses that it's
a huge tasks, even when limiting to the major ones.
but your expertize there would be more than welcome. I've even a
developer who should be interested in working on this too.

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

I'd like to send you a UPS unit so that you can play a bit more with
NUT and its outlet collection.
if you're interested in, please send me back (priv) a delivery
address, with a phone (you live in the US seems?)

To conclude this first "meeting", the best would be:
- to have a common ground for comparison (ie having 1 same device
supported by both, and check how things works on each side),
- possibly try to make a quick and dirty bridge between nut and
powerman to see if it make sense (is there a client API to bind with
Powerman?),
- in the meantime, check how hard it would be to merge Powerman's
devices into NUT.

I'll also check on my side your simulators, since I don't own any of
the Powerman's supported devices...

Does all this make sense for you?

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/

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