[fm-discuss] Re: FMRI Reference Documentation?

[Gavin Maltby]

Hi,

On 09/22/06 20:41, Robert Cibrario wrote:
> Right on - a reference list of (all) fault MSG-ID codes is what I seek.
 > I'm looking to enable SNMP (trap) reporting of FM events and need to
 > know what to have my trap receiver guys code against. I've read that
 > Ereports are non public - most undestandable. I'm somewhat dismayed,
 > however, to find that FM output (Freports, MSG-ID) particularly as
 > it relates to SNMP reporing is not yet public.

I'll bring this up at our staff meeting tonight.

So that I can unserstand your view of the problem, can you tell me
what it is you will do with a list of fault codes?  Is there a
particular piece of information that is missing from the MIB
that you are trying to recover (such as the severity, impact,
response action) or is it that you wish to summarize
the knowledge article information in the processing tool
so that you can advise impact/action etc without reference
to the knowledge articles?

Publishing a list of fault codes has a few problems for us:

  - we'd have to decide a level of commitment to the stability of
    the list - i.e., decide what restrictions such publication would
    put on our modifying the list

  - whenever the list does change you'll likely want to know if those
    changes affect your systems - i.e., do you have to update your
    software?  This is helped by messages being divided into dictionaries.

  - we need to avoid publishing aspects of unreleased products - internal
    process issue

  - we need to publish the list on a per-release/update or per-patch-level
    basis (and that assumes dictionaries will never be spread across patchids)

  - ...

Nothing impossible.

In the interim, have a look at

     http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/fm/dicts/

Those are the message possible in *Nevada* under the ON consolidation
(most/all messages).  There is probably >90% overlap with S10U2 but
there's probably some divergence, too.  The lists are cumaltive - the
event registry does not support deletions so even the occasional
obsoleted entry will still show up the the .dict file.

These are generated files (from the event registry), but the .po files
contain most of what you want to know (modulo some of the gaps above).

Cheers

Gavin


-- 
Gavin Maltby, Solaris Kernel Development.