Redfish client use case for Software Image ExtendedVersion?

Patrick Williams patrick at stwcx.xyz
Sun May 24 00:05:27 AEST 2020


On Fri, May 22, 2020 at 02:07:58PM -0500, Gunnar Mills wrote:
> Anyone have a Redfish client use case for Software Image ExtendedVersion 
> or see value in it being added to Redfish?
> 
> Was attempting to get ExtendedVersion added to Redfish's 
> SoftwareInventory schema but Redfish did not see an "end-user / standard 
> use cases". IBM's use case is mostly for development and Redfish's 
> feedback was "single implementation can utilize OEM easily". If someone 
> else has a need, will pass that on to Redfish and hopefully that will be 
> enough to get it added to the schema.
> 
> Some background:
> ExtendedVersion - "Extended version of the level.". A value from an 
> OpenPOWER system:
> "ExtendedVersion": 
> "buildroot-2019.05.3-17-g522600d,skiboot-v6.5-242-ge19dddc5-p37cfc70,hostboot-820a099-pe030f7b,occ-3ab2921,linux-5.4.25-openpower1-p2339fe8,petitboot-v1.12,machine-xml-0f9b366-p7fb7a8d,hostboot-binaries-hw013120a.opmst,capp-ucode-p9-dd2-v4,sbe-0a77603,hcode-hw031620a.opmst"
> 
> More information:
> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/ExtendedVersion.interface.yaml
> https://redfish.dmtf.org/schemas/SoftwareInventory.v1_3_0.json
> https://redfishforum.com/thread/301/firmware-extended-version
> Some additional discussion (summarized above) in Redfish issue #4000.*
> *You must have access to the private Redfish repo to view.
> 
> Thanks!
> Gunnar
> 

I don't know enough about Redfish to say that we need ExtendedVersion
directly exposed or not.  Two thoughts though:

1. How do we represent information about a software package which is a
   collection of other things?  What you described with the OpenPOWER
   ExtendedVersion is effectively that, but we have other cases where we
   have an update which is a collection (such as BMC + host together).

2. One common problem we run into is that there is a lot of devices for
   which the update type might be "Other" because we don't explicitly model
   that device.  One change I'd like to make is for us to be a little
   more formal about the ExtendedVersion going forward to better
   identify what the "Other" is.  I intend to propose this similar to the
   Compatible decorator which is being added and defined[1].

Is there sufficiency in what is already defined for Redfish to cover
these two cases or do we need an additional field?

1) https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/31670

-- 
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/20200523/8772e933/attachment.sig>


More information about the openbmc mailing list