Bug 505020

I agree with accepting your patch but currently we don't have enough resources to support it. Cloned to Fedora rawhide (community version of cluster suite) where I will include it and also for RHEL 6, in case something will change.

@Gordan:

According to manual eRIc G4 should support IPMI 2.0; so it should be possible to use fence_ipmilan agent. Can you test it, please?

Gee, thanks for waiting for a response before labeling it as "WONTFIX".

The IPMI support is only for proxying IPMI, and only applies to machines that have IPMI capable motherboards. This is only useful in really bizzare cases where IPMI is available on the motherboard, but not accessible by conventional means (e.g. no on-board NICs, and some ancient Dells had IPMI support via connectors on the MoBo but not accessible via the on-board NICs).

The point is that the eRIC doesn't provide IPMI support unless the support already exists built into the motherboard. For motherboards without IPMI, the only way to use it as a fencing device is the way the attached fencing agent does it, by using the eRIC provided functionality to power the machine on and off via override on the motherboard's ATX power switch.

In other words - eRIC's IPMI support won't help you unless you already have it elsewhere in the hardware. Thus, the fencing agent provided is in no way redundant with any other fencing agents.

You know that won't fix is just something what can make people react faster if they really want something. I just did not know that it will be that fast :)

ok, so IPMI is not usable - I will try to port to it to fence library next week.

Hehe! Somebody pointed out to me that eRIC also supports SNMP. So there is a chance that there is a cleaner way to implement it with SNMP commands, rather than telnet scraping. I may have some time to look into it at the tail end of next week. Will report back.

Thank you for taking the time to enter a bug report with us. We do appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for getting support, and as such we are not able to make any guarantees as to the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain that it gets the proper attention and prioritization to assure a timely resolution.  

For information on how to contact the Red Hat production support team, please see:
https://www.redhat.com/support/process/production/#howto

"That being said, this bug tracking system is not a
mechanism for getting support, and as such we are not able to make any
guarantees as to the timeliness or suitability of a resolution."



I'm not sure where you are getting the idea that this is being treated as anything like a support mechanism. To me, making a code/functionality contribution is about as far removed from requesting support as it can theoretically be. Or am I misunderstanding the point you were trying to make?

(In reply to comment #9)
> "That being said, this bug tracking system is not a
> mechanism for getting support, and as such we are not able to make any
> guarantees as to the timeliness or suitability of a resolution."
> 
> 
> 
> I'm not sure where you are getting the idea that this is being treated as
> anything like a support mechanism. To me, making a code/functionality
> contribution is about as far removed from requesting support as it can
> theoretically be. Or am I misunderstanding the point you were trying to make?    

I was simply pointing out that if you are an existing Red Hat customer and want support for this fence device prioritized it is in your best interests to file a ticket with our support organization.  Otherwise the request will be prioritized differently.

Our support organization is used for both filing bugs/reporting problems as well as requesting new features.  So an RFE is in fact a support issue.

In order for the Raritan fence device to be officially supported we need to have access to the hardware, which presently we do not.  So even if you provide a patch (which is appreciated btw) we probably will not be able to include it in the product in the near future due to lack of hardware availability.

Last time I sent a patch for a Dell DRAC III / DRAC ERA/O fencing agent, the feedback I got implied that you don't have access to that hardware either, yet it is supported (and it was broken when used with the most recent ERA/O firmware). That would imply that hardware availability isn't in fact as much of a show-stopping issue as one may think (let's face it, across the entire supported hardware list, that would be a LOT of hardware).

A previous message above implies that the agent has been pushed upstream to Fedora. Has this been undone? I cannot see it in the cman package in FC13a.

@Gordan:

No it was not pushed to fedora yet. You said you will look at SNMP on this fence device. I just do not want to push/unpush fence agents - if you say that this is final version, I will put it in upstream of fence-agents (used in Fedora). Not all of the fence agents in upstream/Fedora are supported in RHEL/RHEV environment.

Acknowledged. I will look into the SNMP possibility by the end of the week. Meanwhile, since there is fence_apc _AND_ fence_apc_snmp, it would seem there is precedent (for whatever the original reasoning may have been) to include both the telnet-scraping and SNMP variants?

Ok. I agree with apc / apc_snmp are precedent and there is real chance that we will remove them from upstream (not RHEL as there is support for them) when we will have enough time. E.g. we did not add telnet-scraping variant for iDrac 6 as we found out that ipmi works correctly on these machines.

Writing (and supporting) code written for SNMP fence agents is easier and usually we don't have to change code due to differences in firmware. So it will be a preffered solution.

Yes there is precedent for this, but we would really prefer to standardize on snmp and ipmi interfaces since screen scraping can be problematic as firmware versions change.  The reason for having apc and then apc_snmp is that snmp wasn't available until later in the apc products.  For new fence agents if ipmi/snmp exist we don't want to screen scrape if we can use a standardized interface.

Also, my comment above about support was just directed at the RHEL/RHEV products which are sold/supported by Red Hat.  Of course for upstream inclusion (Fedora and the cluster stack upstream trees) my comments don't apply.  The rules for inclusion upstream are much more loose :)

If the agent is snmp/ipmi based then we wouldn't need access to the hardware since we'd rely on the hw implementing a standard interface.  (I admit in the past we've been more loose about this and have accepted agents that we weren't able to validate directly, but we're trying to be more conservative about this from a product support perspective)

Too late for adding new hw support for RHEL5, possibility to add to RHEL6 is still open