HPI General FAQ - Events and Event Logs

Clarifications on Resource and Domain Event Logs

HPI provides access to two kinds of event logs – the Domain Event Log, and optional Resource Event Logs. This FAQ discusses the subtle differences between the two kinds of event logs.

The Domain Event Log is mandatory for each Domain. Each Resource may optionally support an Event Log. An HPI User can determine if a resource has an associated Event Log, by examining the SAHPI_CAPABILITY_EVENT_LOG flag in the RPT capabilities.

Where does an event “go”?

The first detail to understand is what happens when an event actually occurs. The event can go to many places. The event will typically go to both an Event Log and an event queue. The event queue is the mechanism used for asynchronous eventing via the saHpiEventGet() function. Note that because this FAQ is discussing Event Logs, the event queuing features are mentioned briefly here for completeness, but are not discussed in detail.

In actuality, when an event is generated, it may be placed in multiple event logs.

Looking at figure A below, an event from Resource, R1 goes to the R1 Resource Event Log, and to the Domain Event Log. R1’s event is shown in blue. But an event from Resource, R2, would go only to the Domain Event Log. R2’s event is shown in orange.

Once an event is placed into an Event Log, it is referred to as an Event Log Entry. One might see this situation in the figure below a bladed chassis system. The Domain Controller would typically be implemented on some type of management controller. Resource R1 would represent a processing blade that contains some physical event log storage on that blade. And Resource R2 would represent something like a hot-swappable fan tray that has no on-board storage for Event Logs.

What information is accessed when an HPI User accesses either of the Event Logs?

When a single HPI User starts up, if they want historical information they will want to read the Domain Event Log. This is because some of the events may not have been placed into a Resource Event Log. (The event from R2 in the figure above is an example of this.)

Though normally, an HPI User will want to retrieve entries from the Domain Event Log, there may be situations where it is appropriate to retrieve entries from the Resource Event Log. One such situation may occur if they wish to retrieve filtered information that applies to R1 only. Another, more likely situation occurs when they want to see if there’s information contained in the Resource’s Event Log that is not contained in the Domain Event Log. This could occur if, for instance, R1 was inserted into the system with some Event Log Entries currently existing in its event log (some “old events” in the R1 event log shown in the figure above).

Note that the HPI Event Log capability originates from the desire to expose historical logs, which are present on many of today’s telco-oriented hardware platforms. In order to properly accommodate these systems, the HPI specification allows the exact population of entries in each Event Log to be determined by the HPI Implementation. (Refer to paragraph 5 of section 6.4, on page 64 of the HPI B.01.01 specification: “Exactly what events are placed in the Resource and Domain Event Logs and how long they remain in the Event Log are implementation-specific.”) Because of this implementation-specific nature of Event Logs, an HPI User is cautioned that an HPI Event Log may not contain a full record of events. Therefore the already mentioned Event Queue functionality with the API call saHpiEventGet() should be used for the management of the system. What happens when event logs are cleared?

Each Event Log is cleared independent of other Event Logs in the system. As such, a call to saHpiEventLogClear with the appropriate session context and a Resource ID of for R1 would clear the contents of the R1’s Event Log. Such a call would have the effect shown in the figure below, where the Domain Event Log contains all of its Event Log Entries, but the Resource Event Log is cleared of all of its Event Log Entries. Note that the Event Log Entry from R1 remains in the Domain Event Log after the clear operation.

If, instead, an saHpiEventLogClear() operation was issued to the Domain Event Log by addressing the appropriate session context and using the Resource ID, SAHPI_UNSPECIFIED_RESOURCE_ID, the Domain Event Log would be cleared, without affecting the Resource Event Log. This is shown below:

What happens when R1 is extracted from the system?

When a Resource with an Event Log capability is removed from the system, the Resource’s Event Log ceases to exist. Though the Resource Event Log is no longer in service, the historical Event Log Entries from that Resource are still captured in the Domain Event Log. This is shown below.

On another note, once Resource R1 has been extracted, its RPT entry and RDRs are also removed from the HPI model. When an HPI User reads the Event Log Entry for R1 out of the Domain Event Log under this condition, there is no context to explain what R1 was, or what the management instrument creating the event was meant to do. The optional parameters for the RPT and RDR that are returned with saHpiEventLogEntryGet() are meant to give an HPI User context about the Resource and the management instrument, under these circumstances.