Hi David,
See my answers below.
Anton Pak
On Tue, 20 Sep 2011 02:07:59 +0400, David McKinley <[email protected]>
wrote:
> Hello,
>
> I've been digging into OpenHPI over the last few days, with a need to
> adapt it to a new platform. As a result, I've come up with a few
> questions, that I'm hoping someone can provide answers - or at least
> pointers to where I might find more information. If you have any
> insight on any of the following, can you let me know?
>
> Thanks!
>
> a) On the web page http://openhpi.sourceforge.net/status, there is a
> chart showing the status of HPI functions in various plugins. It
> reports that for the IPMI Direct plugin the following are "broken" -
> saHpiEventLogEntryAdd, saHpiEventLogStateSet,
> saHpiEventLogOverflowReset, saHpiIdrAreaAdd, saHpiIdrAreaDelete,
> saHpiIdrFieldAdd, saHpiFieldSet, saHpioIdrFieldDelete,
> saHpiWatchdogTimerGet, saHpiWatchdogTimerSet, saHpiWatchdogTimerReset.
> Is this chart up to date? That is, are these functions, in fact broken
> in the IPMI Direct plugin?
The page is rather old (2004).
I hope that watchdog functions are functional right now.
Inventory and Event Log are still read-only.
However any event log that plug-in provides is a resource event log that
maps to IPMI SEL.
Adding HPI event to IPMI SEL makes no sense.
>
> b) I see a number of references in the documentation that suggests that
> OpenHPI depends on the idea that there will not be two different
> resources that have the same entity path in their RPT entries. In the
> latest HPI specification, it makes it clear that it is legal for
> different resources to have the same entity path, and even gives an
> example of a case where that would be appropriate. Is it correct that
> this is a limitation in OpenHPI? If so, have there been any discussions
> about removing this limitation?
See feature request #3095631.
Currently this is a fundamental limitation.
A plug-in requests new Resource Id from OpenHPI Daemon using Entity Path.
The daemon maintains persistent Entity Path <-> Resource Id map in uid_map
file.
>
> c) I've seen an old bug -
> #2782786<http://sourceforge.net/tracker/?func=detail&aid=2782786&group_id=71730&atid=532251>
>
> - that says, in part, "DAT implementation removes sensor alarm only if
> there is deassertion event for the previously asserted event state that
> raised alarm." That would certainly be a bug, as the HPI specification
> requires the DAT be maintained independently of whether deassertion
> events are generated for a sensor. For example, in an HPI
> implementation I worked on earlier, I addressed this by making sure that
> deassertion events were always generated internally, letting them get
> processed to the point where the DAT was updated, and then deleting them
> before sending to the user if the sensor was not configured to actually
> generate the deassertion event. The description in this bug, though,
> makes it sound like maybe something else was done in OpenHPI to address
> this problem, using Sensor Optional Event Data fields somehow. I'm not
> sure how that works, though, if there isn't an event generated in the
> first place. Does OpenHPI require deassertion events to maintain the
> DAT properly?
If sensor event contains current state in optional event data the DAT will
be maintained according to that state.
See oh_detect_sensor_event_alarm() in openhpid/alarm.c
However if you change deassertion mask for sensor that raised alarm, the
alarm is to be removed from the DAT.
Function oh_detect_sensor_mask_alarm (openhpid/alarm.c) is called from
inside of saHpiSensorEventMasksSet().
There is a comment:
/* Find matching sensor alarms and compare alarm's state with
the deassert mask. If deassert for that state is being disabled
on the sensor, then remove the alarm.
*/
>
> d) Is there any description anywhere about how the IPMIDirect code is
> architected? There is a lot of code there, and I haven't yet found
> anything that helps me figure out where to start understanding it. One
> thing, in particular, I'm wondering about: How does it maintain current
> status of sensors? Does it register to receive IPMI events, or PET
> Alerts, or do some sort of polling? But, more general than that, is
> there any description I can read about its basic organization and design?
No description to my knowledge. If you ask questions in this mailing list
there is a chance to get some architecture view.
Usually IPMI Direct polls BMC SEL periodically and collects new events
from there.
See cIpmiMcThread::ReadSel() in ipmi_discover.cpp.
In addition I see that event may come from IPMI ReadEventMsgBuffer command
response.
However no party in IPMIDirect issues this command.
>
> e) I've been trying to understand what support OpenHPI provides for
> DRTs. I see that there is an API, oHpiDomainAdd - does that let you add
> or remove entries in the DRT of a domain? Or is it just used for adding
> a domain itself in a daemon? What I am imagining is that a plugin would
> have the intelligence to know that when a certain resource is added
> (say, for a blade), then the DRT should also be updated to indicate that
> there is now a new domain that the user should try to access - which
> would provide in-band management for that blade, via a different daemon
> process. Is that sort of function provided somehow? That is, is there
> an API a plugin can call to manipulate the contents of the DRT?
Currently OpenHPI provides empty DRT.
We argued about the ways to design it but came to no conclusion.
OpenHPI has two parts: Base Library and Daemon.
Base Library talks to Daemon over network.
Base Library has openhpiclient.conf configuration file.
Daemon has openhpi.conf configuration file.
It is not clear which part shall maintain DAT.
Before 2.10 domains and DAT were on Daemon side.
Now we have domain configuration on Base Library side and One Daemon - One
Domain rule.
However Base Library can be used to connect to other HPI implementation
(not only to OpenHPI Daemon).
And the other HPI implementation may have its own way for domain/DRT stuff.
And an OpenHPI daemon plug-in may have knowledge about other OpenHPI
daemon instances.
For example if there is HPI on the blade payload and the blade is just
come to ACTIVE state.
Your thoughts look reasonable. Let's try to scratch architecture for that.
oHpiDomain*() API is Base Library API to dynamically maintain known domain
list (known to the Base Library).
>
> f) Similarly, I see how you can define the IP address for an IPMI
> controller as a "handler" entry in the openhpi.conf file. I believe
> I've seen references to the fact that you can actually have more than
> one of these at a time configured. Assuming that is true, is it
> possible to dynamically update the set of IP addresses? For example, a
> connection to a system-manager service processor might provide
> information to the plugin that lets us know that there is now an
> additional service processor that can be connected to over RMCP+. Is
> there an API that can be used to update the "handler" configuration on
> the fly to now make the connection to that next plugin?
Yes, you can have more than one handler and more than one handler instance
of the
same plug-in.
There is API for dynamic handler configuration:
- oHpiHandlerCreate()
- oHpiHandlerDestroy()
- oHpiHandlerInfo()
- oHpiHandlerGetNext()
- oHpiHandlerFind()
- oHpiHandlerRetry()
About one year ago Uli Kleber created ohhandler client application for
this API.
You also can call this API from you plug-in.
>
>
> Again, thanks for any pointers anyone can give.
>
> David McKinley
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
