Redfish multi-host hint in entity-manager

[Patrick Williams]

Hello,

I wanted to raise awareness of a proposed dbus interface to be used as a
hint in bmcweb to implement the multi-host Redfish support:

    https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/72414

Meta now has two systems upstream that are considered "multi-host":
Bletchley and Yosemite4.  This means that a single BMC manages multiple
host computer systems, which are usually populated as some kind of
"blade-like" device into a larger chassis.  We've been enhancing most of
the backend applications over the last 2 years to facilitate this, but
we've been slow at getting Redfish support in bmcweb for it.

The original design in most of the applications was/is that if you have
a dbus path like ".../hostN", then "host0" refers to the single-host
system and "host[1-N]" refer to individual locations in a multi-host
system.  While this design point is relatively easy to implement it
presents a challenge for bmcweb: how do you define an external endpoint
URI name and map it to internal dbus objects?  The typical "single-host"
approach has been to hardcode a Redfish URI (like "/system") to the
corresponding single-host dbus object.  The preference from the bmcweb
maintainers is that this is done in a less hardcoded way.

The typical approach to this, for elements where we have multiple of
them, is that bmcweb can do some sort of mapper query to find them all.
Sensors, inventory, etc. typically operate this way.  However, for
multi-host backend elements we usually don't have an obvious way to name
the URI due to differences in path leaf names across various
applications: hostN, postcodeN, etc.  Ideally, each of these backends
would have some consistent name, path or association to something
consistent that bmcweb can always use for creating the URI, but this
will take work.

My proposal in the short-term is to use entity-manager configs to create
a "hint" interface for bmcweb: Inventory.Decorator.ManagedHost.  This
interface will have an index property which can be used to find the
appropriate backend.

A quick summary of the design and changes would be:

- Inventory.Decorator.ManagedHost is defined and implemented in
  multi-host entity-manager configs.  This will add the interface to
  entity-manager paths such as
  "/xyz/openbmc_project/inventory/Sentinel_Dome_3" (with index = 3).

    - https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/72414

- bmcweb will maintain the existing "Systems/system" URI for single-host systems
  [for a time] (using the redfish-system-uri-name meson option).
  Multi-host systems should set this to an empty string which will
  disable that default URI.

- Inventory.Decorator.ManagedHost will be used by bmcweb, via a mapper
  look up, to determine all of the ComputerSystem paths.  This means
  that an "/xyz/openbmc_project/inventory/Sentinel_Dome_3" with the
  interface will cause "/redfish/v1/Systems/Sentinel_Dome_3" to become a
  valid URI.  When bmcweb needs to interact with the
  phosphor-state-manager objects, it will use the documented convention
  and the "HostIndex" property to construct the dbus path.

- As time permits, single-host systems with entity-manager configs should
  create their own ManagedHost decorators and after sufficient time has
  elapsed the `redfish-system-uri-name` option will be deleted.  [I'll
  let the bmcweb maintainers determine the timelines here but probably
  at least 6 months from initial support.]

- Once we figure out the set of "strange mappings bmcweb has to do", we
  will follow up with design proposals on those repositories to create
  associations back to the ManagedHosts in the inventory model, which
  bmcweb will be able to use directly [approximately 6-12 months in the
  future].

Are there any gaps or concerns with this proposal?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240626/8e677c4f/attachment.sig>