Todd, Charlene J wrote:

Hi David,

Announcements are a type of Management Instrument (like controls, sensors, etc.).  I would generally see them under the RDR branch of the tree, and not under the event or event log branch of the tree.  Though they sometimes capture events as Annunciator Conditions, they aren’t trying to emulate the event log functionality.

Should the AnnouncementEventLogTable be removed?  This is the question that needs a resolution before the FTF.

I'm reluctant to move the AnnouncementTable from Event branch at this point.  Unless Bill thinks we should I vote to leave it there.   When the next release of the B spec is released we could discuss moving it then.

 

Let me take a quick example:

(1) A resource provides an Annunciator, and it “advertises” as such in its RDR repository

(2) Sometime later a temperature sensor trips a critical threshold

(3) Several things happen in response to the temperature sensor tripping this threshold:

(A)   Assuming events are enabled for this sensor and this threshold of this sensor, an event is created and is put into the event queue

(B)    Assuming events are enabled for this sensor and this threshold of this sensor, an alarm condition is recorded in the DAT

(C)    The event may also optionally (at the discretion of the implementation) be stored in the Resource and Domain Event Logs as appropriate

(D)    And the event may optionally trigger an Annunciator condition to be raised.  This is conditional upon what the rules are for that particular announciator, and what status conditions it considers “announcable”. 

(4) The temperature sensor returns to normal readings

(A) Assuming deassert events are enabled for this sensor and this threshold, a deassert event is created and is put into the event queue

(B) The alarm condition is removed from the DAT

(C ) The deassert event may be added to the event log (implementation-dependent).  Not that the assertion event remains in the event log.

(D) and the deassertion may optionally remove the Announciator condition.  This is conditional upon what the rules are for that particular announciator.

 

If a very similar resource did not provide an Annunciator, the whole scenario would remain the same, except for Steps 1, Step 3D, and Step 4D.

 

Does this help?

 

Charlene

 

 

The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.


From: David Judkovics [mailto:djudkovi@us.ibm.com]
Sent: Friday, August 12, 2005 6:13 AM
To: Todd, Charlene J
Cc: Daniel F de Araujo; bill.swortwood@motorola.com; openhpi-saf-mib-wg@lists.sourceforge.net; David M Judkovics
Subject: Re: [Openhpi-saf-mib-wg] RE: HPI-MIB: AnnouncementEventLogTable
Importance: High

 

Todd, Charlene J wrote:

Dan,

I think I need a bit more context.  What is an AnnouncementEventLog supposed to represent?  HPI has the concept of Event Logs, and another concept of Annunicators – but they aren’t the same thing. 

The is so because there is no Event Type Announcement?


So I’m not too clear what these tables are meant to map to in the HPI world…

Presently we have a table for Announcements under the Event and the EventLog branches of the MIB.  Announcements are Created be writing to the Announcement Table under the Event branch.

Even though there is no Announcement Event type I believe the reasoning was this is where Announcements will be stored (Event branch).  This means they will persist here even if they are ack'd.  If they are deleted they should be removed from this table which is different from the other tables under the Event branch.

I assumed the Announcement table in the EventLog branch is for the storing any events that may be stored in the HPI EventLog.  

Are you saying Announcements will never be identified via saHpiEventLogEntryGet()?

You seem to be saying no.  If this is the case we may not need the table under the EventLog branch.



 

Charlene

 

The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.


From: Daniel F de Araujo [mailto:ddearauj@us.ibm.com]
Sent: Thursday, August 11, 2005 2:37 PM
To: bill.swortwood@motorola.com; Todd, Charlene J; openhpi-saf-mib-wg@lists.sourceforge.net
Cc: David M Judkovics
Subject: HPI-MIB: AnnouncementEventLogTable

 

Bill, Charlene, et al -

While inspecting the hpi-mib today, I noticed that the AnnouncementEventLogTable has a few columnar nodes designated as read-create. The problem is that I don't believe there is actually a way to create a new announcement event log through any of the HPI APIs. The closest API that we could use is saHpiEventLogEntryAdd, however, the spec specifically states that the event field must be of type SAHPI_ET_USER. Should the read-create attributes of the announcement event log table be changed to read-only?

Reference (line 6164 - 6285):

saHpiAnnouncementEventLogSeverity OBJECT-TYPE
SYNTAX SaHpiSeverity
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Only used with DAT and Annunciator functions.
This is not a valid severity for events or alarms."
::= { saHpiAnnouncementEventLogEntry 4 }


saHpiAnnouncementEventLogAcknowledged OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Acknowledged flag."
::= { saHpiAnnouncementEventLogEntry 5 }


saHpiAnnouncementEventLogStatusCondType OBJECT-TYPE
SYNTAX INTEGER {
undefined(0),
sensor(1),
resource(2),
oem(3),
user(4) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Status Condition Type."
::= { saHpiAnnouncementEventLogEntry 6 }


saHpiAnnouncementEventLogEntityPath OBJECT-TYPE
SYNTAX SaHpiEntityPath
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"See Textual-Convention for details."
::= { saHpiAnnouncementEventLogEntry 7 }


saHpiAnnouncementEventLogSensorNum OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Sensor associated with status Only valid
if saHpiAnnouncementEventLogStatusCondType is sensor(1)."
::= { saHpiAnnouncementEventLogEntry 8 }


saHpiAnnouncementEventLogEventState OBJECT-TYPE
SYNTAX SaHpiEventState
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Sensor event state. Only valid if
saHpiAnnouncementEventLogStatusCondType is sensor(1)."
::= { saHpiAnnouncementEventLogEntry 9 }


saHpiAnnouncementEventLogName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"AIS compatible identifier associated with Status condition."
::= { saHpiAnnouncementEventLogEntry 10 }


saHpiAnnouncementEventLogMid OBJECT-TYPE
SYNTAX SaHpiManufacturerId
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Manufacturer Id associated with status condition,
required when saHpiAnnouncementEventLogStatusCondType is oem(3)."
::= { saHpiAnnouncementEventLogEntry 11 }


saHpiAnnouncementEventLogTextType OBJECT-TYPE
SYNTAX SaHpiTextType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Field Data.
See Definition for SaHpiTextType for more details."
::= { saHpiAnnouncementEventLogEntry 12 }


saHpiAnnouncementEventLogTextLanguage OBJECT-TYPE
SYNTAX SaHpiTextLanguage
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Field Data.
See Definition for SaHpiTextLanguage for more details."
::= { saHpiAnnouncementEventLogEntry 13 }


saHpiAnnouncementEventLogText OBJECT-TYPE
SYNTAX SaHpiText
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Field Data.
The type of date is specified
by saHpiResourceTagTextType and saHpiResourceTagLanguage."
::= { saHpiAnnouncementEventLogEntry 14 }


saHpiAnnouncementEventLogDelete OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This function allows the HPI SNMP Manager to delete a single
announcement. Announcements may be deleted individually by specifying
a specific index and setting this columnar node to destroy(6).
"
::= { saHpiAnnouncementEventLogEntry 15 }

Regards,
-Dan

Daniel F. de Araujo
Linux Technology Center
Phone: 512-838-5925
Tie Line: 678-5925