[fm-discuss] Re: Sensor design doc now available

[Garrett D'Amore]

So we have sensors, and indicators.  What about control points?  E.g. I 
want to be able to have a common framework for fans, etc.  (That way I 
can have a rule that says

if (component.temp() > component.temp.warn_threshold() &&
    component.has_fan() && component.fan.get_speed() < 
component.fan.maxspeed()) {
        component.fan.increase_speed();
}

without knowing anything about the implementation of component, or fans.

Also, is this framework really just for system-health related items, or 
should there be some overlap, e.g. with lid switches on laptops? (Which 
are just another sensor, in implementation.)

    -- Garrett

cindi wrote:
>
>
> Eric Schrock wrote:
>> Cindi -
>>
>> I've had a chance to take a closer look at the design doc.  It all looks
>> great, though I have a few high-level questions.  These might belong as
>> "future phases", but it would help to have some explanation in the
>> design document to know that the issues are being considered.
>>
>> How do indicators relate to this work?  I see them mentioned when
>> disucssing the FMRI syntax, but nowhere else.  Are indicators related to
>> this work beyond the FMRI syntax, or is it completely separate?  Is
>> there a separate project to define the role of indicators in libtopo and
>> Solaris?
>
> Support for indicators are really orthogonal to this project but I 
> have included the definition as part of the facility definition as it 
> makes sense.
>
>>
>>> From an implementation perspective, it would help to outline how the
>> facility nodes would will in libtopo.  How do I read sensor values from
>> the nodes?  Do they have all the standard properties of a topo node,
>> minus the obvious restriction of not having any children?
>
> Implemtation-wise, facility (sensor and indicator) nodes are just leaf 
> topo nodes.  We can attach properties and methods just like we do for 
> other types of topo nodes.  I see the manipulation and access of 
> indicators happening via topo methods exported by (hopefully) standard 
> properties.  In this way, the consumer of an indicator does not need 
> to know the implementation details of how we read or write an indicator.
>
> This is similar to the sensor provider layer but can happen as soon as 
> we support facilities in libtopo rather than a future phase of this 
> project.  Your point below applies here as well.  We need to come up 
> with a standard name-type space for indicator props.
>
> I have working prototype of topo facility nodes so we can start 
> thinking about this right away.
>
>>
>> Is there going to be any standardization on the properties exported by a
>> sensor node?  I'm imagining what it would take to construct a generic
>> sensor browser.  While most of this is outside the scope of phase 1, and
>> falls under objective #3 (ability to watch sensors), it seems like some
>> minimal design decisions need to made just to prototype phase 1 and
>> justify the architecture.
>>
>> We want the ability to export arbitrary payloads via sensors, but it
>> seems like if we're not careful we can end up with a fragmented
>> namespace that makes monitoring difficult.  Looking towards the future,
>> it would seem beneficial to define some common set of properties across
>> all sensors, even something as basic as "value", "units", and
>> (optionally) "threshold".
>
> Agreed and the sooner we start thinking about what we want to monitor 
> and how the sooner we can define the namespace.  If you have any 
> ideas, I would like to hear them.
>
>>
>> As a nit, does 'RTN' have to be capitalized?  It seems like all the
>> events in the registry use lowercase names, and the all caps name looks
>> a little off.  Although your fmdump example output uses lowercase, so
>> maybe this is just a case of inconsistency in the document.
>
> We've gone back and forth on that.  The fault manager tends to use 
> caps for acronyms (FRU, ASRU, etc...) so I tried to be consistent with 
> that.
>>
>> Thanks,
>>
>> - Eric
>> -- 
>> This message posted from opensolaris.org
>> _______________________________________________
>> fm-discuss mailing list
>> fm-discuss at opensolaris.org
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris.org