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