All of lore.kernel.org
 help / color / mirror / Atom feed
* Adding a detailed physical model to bmcweb
@ 2020-02-25 22:22 Richard Hanley
  2020-03-11 15:45 ` Brad Bishop
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Hanley @ 2020-02-25 22:22 UTC (permalink / raw)
  To: OpenBMC Maillist

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

One of the requirements we have for our data center management software is
that we need to be able to map resources (e.g. actions, telemetry, and
assemblies) directly to the physical component that it originated from as
well as how those components are physically connected.

Historically this mapping was done through a custom protocol on the host,
and we would like to move this to a Redfish service on the BMC. Another
engineer spoke with DMTF, and the most Redfishy way to represent this would
be by adding links in the assemblies. Some examples of possible
relationships are:

*/Systems/1/Memory/1/Assembly ------> /Chassis/Mobo/Sensors/MemSensor*
*/Chassis/Mobo/PCIeDevices/Storage/Assembly ---------->
/Systems/1/Storage/BootVolume*
*/Chassis/Mobo/PCIeDevices/ExpansionTray/Assembly --------->
/Chassis/ExpansionTray/Assemby*

That last example is actually represented in the current Redfish spec, but
it helps explain the idea I'm getting at.  The hope is that by starting at
the service entry point we can get a physical model of the component tree
by traversing hyperlinks. From that a client could relate any Redfish
resource to its physical component.

Let's just say for the moment that we get a service that collects this
information, I've been trying to figure out a way to sustainably add it
into bmcweb.  Presumably this would be a large amount of OEM material that
OpenBMC wouldn't want to support upstream.

I don't think making patches in bitbake or subclassing the individual nodes
will be sustainable in the long run.  At a minimum a way to chain
co-routines would allow for other code to "attach" to the response handlers.

So I guess there are a couple of questions here.  Does the community have
any plans/desire to support an extension mechanism in bmcweb? If so, should
we be thinking of in-process code extensions or inter-process dynamic
extensions?

For the record, this requirement does not have an imminent deadline, so I
am happy to design around the best long term solution as opposed to a short
term hack.  I just wanted to get a plan here before things become imminent.

Thanks,
Richard

[-- Attachment #2: Type: text/html, Size: 2439 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Adding a detailed physical model to bmcweb
  2020-02-25 22:22 Adding a detailed physical model to bmcweb Richard Hanley
@ 2020-03-11 15:45 ` Brad Bishop
  2020-03-11 16:50   ` Richard Hanley
  0 siblings, 1 reply; 3+ messages in thread
From: Brad Bishop @ 2020-03-11 15:45 UTC (permalink / raw)
  To: Richard Hanley; +Cc: OpenBMC Maillist

at 5:22 PM, Richard Hanley <rhanley@google.com> wrote:

> One of the requirements we have for our data center management software  
> is that we need to be able to map resources (e.g. actions, telemetry, and  
> assemblies) directly to the physical component that it originated from as  
> well as how those components are physically connected.
>
> Historically this mapping was done through a custom protocol on the host,  
> and we would like to move this to a Redfish service on the BMC.

Hi Richard.  We (IBM) also have a need for the same detailed mapping  
information but from other services on the BMC.

> Let's just say for the moment that we get a service that collects this  
> information


Right, so where we have shared interest I think is how this service works  
and exports its information to _any_ BMC service (not just bmcweb -  
exporting the mapping information via external interfaces is less of a  
priority over here).  Can you say any more about this service?

thanks!

-brad

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Adding a detailed physical model to bmcweb
  2020-03-11 15:45 ` Brad Bishop
@ 2020-03-11 16:50   ` Richard Hanley
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Hanley @ 2020-03-11 16:50 UTC (permalink / raw)
  To: Brad Bishop; +Cc: OpenBMC Maillist

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

>Right, so where we have shared interest I think is how this service works
>and exports its information to _any_ BMC service (not just bmcweb -
>exporting the mapping information via external interfaces is less of a
>priority over here).  Can you say any more about this service?

I'm not sure at the moment.  Google has some software that runs on the host
machine to build a physical model.  I'll check in with the developers to
see if what they are doing is applicable to a BMC.  I'll follow up once I
get a better idea on how this service could be constructed.

Thanks,
Richard

On Wed, Mar 11, 2020 at 8:45 AM Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> at 5:22 PM, Richard Hanley <rhanley@google.com> wrote:
>
> > One of the requirements we have for our data center management software
> > is that we need to be able to map resources (e.g. actions, telemetry,
> and
> > assemblies) directly to the physical component that it originated from
> as
> > well as how those components are physically connected.
> >
> > Historically this mapping was done through a custom protocol on the
> host,
> > and we would like to move this to a Redfish service on the BMC.
>
> Hi Richard.  We (IBM) also have a need for the same detailed mapping
> information but from other services on the BMC.
>
> > Let's just say for the moment that we get a service that collects this
> > information
>
>
> Right, so where we have shared interest I think is how this service works
> and exports its information to _any_ BMC service (not just bmcweb -
> exporting the mapping information via external interfaces is less of a
> priority over here).  Can you say any more about this service?
>
> thanks!
>
> -brad
>

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-03-11 16:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-25 22:22 Adding a detailed physical model to bmcweb Richard Hanley
2020-03-11 15:45 ` Brad Bishop
2020-03-11 16:50   ` Richard Hanley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.