[fm-discuss] Proposal: libtopo eumeration of power supplies and fans via IPMI

[Eric Schrock]

On Tue, Jan 08, 2008 at 10:27:39AM -0800, Cynthia McGuire wrote:
> 
> I see no reason to limit the number of chassis's to one.  There are 
> plenty of examples where there are more than one chassis in which these 
> (and other) components reside.  Also, in the topology, does the 
> motherboard become a sub-component (child) of a chassis or is it a peer 
> (sibling)?

Yes, the statement of there only being one chassis was bit of a
misnomer.  For the current phase of the project we are only targeting
systems that support a single chassis, because it is unclear whether
IPMI is used on these systems and whether the reported topology includes
chassis outside the one upon which the system is running.

It would certainly be nice to move 'motherboard' under the chassis as
well as the 'bay' nodes, but I know in the past it has been inferred
that doing so will break existing diagnoses.  Is it allowable to
rearrange the topology in this fashion?

> > Each component that is directly under the chassis will be assigned a FRU
> > matching its resource.  
> 
> What does this statement mean?  Are you saying that the FRU property for 
> a topo node directly under 'chassis' will be equal to the resource 
> property?  What does the FRU label property look like?
> 
> Components within an association will default to
> > the FRU of their parent, unless they have associated FRU locator
> > records, in which case they will have a distinct FRU matching their
> > resource.
> 
> The paragraphs above use the acronym, FRU, to mean FRU label and FRU 
> FMRI.  Both of which are properties for a give topo node.  Please be 
> clear about which you're talking about.

In these statements the term FRU refers to the FMRI, not the label.
We're not 100% sure on what to use for the label, but the default will
likely be a per-chassis incremented counter of the form "FAN %d" and
"PSU %d".  Unfortunately, there is no label property available via IPMI.
We could use a heuristic that would work for Sun ILOM platforms
("ft0.fm1.fru" -> "ft0.fm1"), but the naming of SDR records is
arbitrary.  We could also do "FM %d FAN %d" instead of the global
identifier, which is probably closer to what would be silkscreened on
the chassis.

When dealing with fanmodules and fans, the following would be a
reasonable topology:

	hc:///chassis=0/fanmodule=0
	    FRU: hc:///chassis=0/fanmodule=0
	    label: FM 0

	hc:///chassis=0/fanmodule=0/fan=0
	    FRU: hc:///chassis=0/fanmodule=0
	    label: FM 0 FAN 0

	hc:///chassis=0/fanmodule=0/fan=1
	    FRU: hc:///chassis=0/fanmodule=0
	    label: FM 0 FAN 1

	hc:///chassis=0/fanmodule=1
	    FRU: hc:///chassis=0/fanmodule=1
	    label: FM 0

        ...

I'll let Rob respond to the libtopo comments.

- Eric

--
Eric Schrock, FishWorks                        http://blogs.sun.com/eschrock