RFC: Inventory functional state tracking

[Brad Bishop]

> On Jan 22, 2017, at 10:51 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Sun, Jan 22, 2017 at 09:31:54PM -0500, Brad Bishop wrote:
>> Looking for ideas on tracking inventory item functional state.  If this interests you, please read on.
>> 
>> One approach would be to add a functional state DBus interface to inventory objects.  I was hoping to
>> keep dynamic/state information out of the inventory namespace as much as possible, but the inventory manager
>> could probably be made to set properties on an interface when specific conditions are met.
>> 
>> Another approach would be a new class of sensor applications that do whatever is required to monitor the functional
>> state of one or more inventory items.  For functional status of inventory coming from the host this would
>> probably be host-ipmid.  These applications would provide sensor objects in a sensors/fault
>> namespace, possibly with a xyz.openbmc_project.Sensors.Fault interface.  The fault sensor objects would be associated
>> back to their inventory item via an association object.
> 
> I'm not a fan of calling something a Sensor unless it really is.  That
> is what IPMI does and it ends up being a catch-all for everything else.

I’m having a hard time distinguishing between state and sensors.  What is a sensor other than
something that reports state on something else?  What makes IPMI goofy is that part numbers
are “sensed” in addition to the functional state.

> Something under xyz.openbmc_project.State seems more appropriate to me

State also feels catch all to me.  Would the objects implementing this interface go in /xyz/opembmc_project/state ?

We have (or will have) these namespaces:

/xyz/openbmc_project/inventory
/xyz/openbmc_project/sensors
/xyz/openbmc_project/control
/xyz/openbmc_project/records

(an unrelated question - what other namespaces make sense for OpenBMC?)

What would be the rule of thumb for putting something in the sensors vs the state namespaces?

> but following the rest of your concept the same.

If you like the concept just not the names…ok… I won’t get hung up on it.  What do you think of having
the inventory manager handle it?  One problem I can see with this approach is if the logic for detecting
a failure becomes too complicated an application would have to be written with it anyway, to make it
simple enough for the inventory manager to act on.

> 
>> 
>> Please poke holes..ask questions.
> 
> What process would end up managing functional states?  The same process
> that handles the inventory for an element or some other process?

I’m not sure I can answer this in a general sense yet.  For host inventory, host-ipmid has to play at least some role right?

> 
> -- 
> Patrick Williams