RFC: Inventory functional state tracking

RFC: Inventory functional state tracking

[Brad Bishop]

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.

Please poke holes..ask questions.

thx - brad

Re: RFC: Inventory functional state tracking

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

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.

Something under xyz.openbmc_project.State seems more appropriate to me
but following the rest of your concept the same.

> 
> 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?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: RFC: Inventory functional state tracking

[Brad Bishop]

> On Jan 22, 2017, at 10:51 PM, Patrick Williams <patrick@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