This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 505020 - Fencing Agent for Raritan eRIC G4
Fencing Agent for Raritan eRIC G4
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cman (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Marek Grac
Cluster QE
: Reopened
Depends On:
Blocks: 519731 519732
  Show dependency treegraph
 
Reported: 2009-06-10 08:04 EDT by Gordan Bobic
Modified: 2016-04-26 12:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 519731 519732 (view as bug list)
Environment:
Last Closed: 2011-07-01 06:42:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fencing agent for Raritan eRIC G4 (6.39 KB, text/plain)
2009-06-10 08:04 EDT, Gordan Bobic
no flags Details

  None (edit)
Description Gordan Bobic 2009-06-10 08:04:13 EDT
Created attachment 347212 [details]
Fencing agent for Raritan eRIC G4

Not a bug, but a feature request with a proposed patch.

There is currently no fencing agent for Raritan eRIC G4 devices (similar to DRAC and ILO). Attached is a fencing agent for the eRIC G4 devices. As all the current fencing agents, this one is also written in perl and has the same requirements as the others (Getopt::Std, Net::Telnet).
Comment 2 Marek Grac 2009-08-27 11:32:46 EDT
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.
Comment 3 Marek Grac 2010-03-20 14:43:21 EDT
@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?
Comment 4 Gordan Bobic 2010-03-20 15:11:45 EDT
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.
Comment 5 Marek Grac 2010-03-20 15:22:35 EDT
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.
Comment 7 Gordan Bobic 2010-03-20 19:06:57 EDT
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.
Comment 8 Perry Myers 2010-03-21 08:49:11 EDT
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
Comment 9 Gordan Bobic 2010-03-23 10:54:24 EDT
"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?
Comment 10 Perry Myers 2010-03-24 11:28:37 EDT
(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.
Comment 11 Gordan Bobic 2010-03-24 11:43:16 EDT
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.
Comment 12 Marek Grac 2010-03-24 11:53:45 EDT
@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.
Comment 13 Gordan Bobic 2010-03-24 12:03:21 EDT
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?
Comment 14 Marek Grac 2010-03-24 12:17:46 EDT
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.
Comment 15 Perry Myers 2010-03-24 12:18:05 EDT
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)
Comment 19 Marek Grac 2011-07-01 06:42:09 EDT
Too late for adding new hw support for RHEL5, possibility to add to RHEL6 is still open

Note You need to log in before you can comment on or make changes to this bug.