[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] Eaton fence agent and more power devices support

Hi Marek,

2011/1/20 Marek 'marx' Grác

Arnaud Quette wrote:
Hi Marek and the list,

First of all, happy new year to you all: health, happiness and ... high availability ;-)

I've just derived a fence_eaton_snmp script, based on fence_apc_snmp.
You'll find attached the diff against the latest fence-agents repository.

This has been tested with the suitable hardware (Eaton Managed ePDU): http://www.epdu.com
Can you please merge this for the next cman releases.

Finally, I was able to review your code. I have few minor suggestions how to make code be better but we can solve that later. But I can do that later when we will have an access to this device. Fence agent will be part of the next fence-agents package.

excellent, thanks.
Do you have any idea about the next official release date?
I'm still checking with Fabio to provide a suitable device for Denmark.
is it fine for you to access it that way?

As a side note, I'm thinking about:
- making one fence_pdu_snmp to group all this code (sysOID brings the smartness of knowing which data should be used), or at least create some common grounds to factorize code,

- making a fence_nut_devices (or fence_power_devices) to use NUT [1] to do the same for all supported serial / USB / SNMP / HTTP devices (ie UPS, PDU and SCD).

I'm not against unfication but at least for power fencing - most of the shared code is already in fencing library and some agents differs a lot. Benefit of this simple agents is that we can't break anything else :) and code is already simple/small enough. In the case of SNMP based fence agents, it is possible that now as we have several such agents we can try to implement general solution.

if you diff between fence_apc_snmp and fence_eaton_snmp, you'll see that there are few diffs.
the idea would be to merge these in a fence_pdu_snmp, since it will only be limited to adding 1 struct for addressing outlets, and 1 entry in the general table.
The thing is that, using NUT knowledge base, we would be able to add more data for other PDUs.

And a fence_nut would not be hard to create, to address all devices supported by NUT (both UPS and PDU), whenever there is already a NUT framework deployed...

Don't hesitate to ping me back once you have some time to discuss this.

Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]