Proposed bmcweb dump LogService "Name" change

[Claire Weinan]

Thanks Ed for your response.
I have opened an issue at https://github.com/DMTF/Redfish/issues/5326
When we discussed it at the Redfish working group meeting today the group
generally supported adding one or more new properties to the LogService
schema for describing a log's "purpose" (i.e. content type, in contrast to
format type). (It seemed like using "Name" to differentiate a log's purpose
is possible but not encouraged.) The next step will be to create a proposal
for the new properties.

Best Regards,
Claire

On Mon, Oct 31, 2022 at 8:53 AM Ed Tanous <edtanous at google.com> wrote:

> On Tue, Oct 25, 2022 at 6:19 PM Claire Weinan <cweinan at google.com> wrote:
> >
> > Hi All,
> >
> > I have opened a bmcweb code review (
> https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57949) proposing a change
> to the "Name" property of dump LogServices. This is best shown with
> examples:
> >
> > Example from /redfish/v1/Managers/bmc/LogServices/FaultLog:
> > Before: "Name": "Dump LogService"
> > After: "Name": "FaultLog Dump LogService"
> >
> > Example from /redfish/v1/Managers/bmc/LogServices/Dump:
> > Before: "Name": "Dump LogService"
> > After: "Name": "BMC Dump LogService"
> >
> > Example from /redfish/v1/Systems/system/LogServices/Dump:
> > Before: "Name": "Dump LogService"
> > After: "Name": "System Dump LogService"
> >
> > Are any Redfish clients currently matching on this "Name" value? If so,
> would it be feasible to change from checking if "Name" equals "Dump
> LogService" to checking if "Name" contains "Dump LogService"?
> >
> > ---
> > Details on the reasoning for changing to a more specific name:
> >
> > This allows a client to differentiate the dump types of various dump
> LogServices based on the "Name" property. (For example, the client might
> only be interested in examining LogServices of one particular dump type.)
> >
> > From Redfish spec v1.16.0, section 9.6.7 "Name": "The Name property
> conveys a human-readable moniker for a resource. The data type of the Name
> property shall be string. The value of Name is NOT required to be unique
> across resource instances within a resource collection."
> >
> > Based on the above, the primary purpose of "Name" is to be a
> "human-readable moniker”. I did not find a statement in the Redfish spec on
> whether it can be used for type matching.
> > One type-related property in the LogService schema is "LogEntryType" --
> however the possible values (Event, Multiple, OEM, SEL) aren't fine-grained
> enough to determine the exact dump type for this use case.
>
> Please open a discussion in a DMTF forum to discuss this.  Not finding
> a statement would imply that there's something that needs to be
> changed in the redfish specification itself.
>
> >
> > So in the absence of another suitable LogService property for a client
> to use to differentiate between dump types (and various OEM LogService
> types in general), we opt to use the "Name" property.
>
> Lets get clarification from the standards body on how this feature is
> intended to work (I believe there's already some discussion going on)
> and go from there.  Depending on what the decision is, we can decide
> what the next steps are, but as proposed, this would make the "Name"
> field part of the unchangeable API.  When we've hit this issue before
> in the case of sensors, we ended up making it a system-specific
> decision.  I'm not sure that's the right approach here.
>
> As an added comment, there are more than just OpenBMC systems out
> there running Redfish, so if we actually want to use the Name field
> for this purpose, it would need prefixed with "OpenBMC" to
> differentiate it from other types of logs with similar naming.
>
> >
> > Best Regards,
> > Claire Weinan
> > --
> >
> > Claire Weinan
> > Software Engineer
> > cweinan at google.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20221101/f884a9c7/attachment.htm>