<div dir="ltr">Just an update: I have created a pull request (<a href="https://github.com/DMTF/Redfish/pull/5336">https://github.com/DMTF/Redfish/pull/5336</a>) at the Redfish github proposing a new LogPurpose (enum) property and a new OemLogPurpose (string) property in the LogService schema, and welcome feedback on them.<br><div><br></div><div>Best Regards,</div><div>Claire</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 1, 2022 at 1:16 PM Claire Weinan <<a href="mailto:cweinan@google.com">cweinan@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Ed for your response.<div>I have opened an issue at <a href="https://github.com/DMTF/Redfish/issues/5326" target="_blank">https://github.com/DMTF/Redfish/issues/5326</a></div><div>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.</div><div><br></div><div>Best Regards,</div><div>Claire</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 8:53 AM Ed Tanous <<a href="mailto:edtanous@google.com" target="_blank">edtanous@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 25, 2022 at 6:19 PM Claire Weinan <<a href="mailto:cweinan@google.com" target="_blank">cweinan@google.com</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> I have opened a bmcweb code review (<a href="https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57949" rel="noreferrer" target="_blank">https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57949</a>) proposing a change to the "Name" property of dump LogServices. This is best shown with examples:<br>
><br>
> Example from /redfish/v1/Managers/bmc/LogServices/FaultLog:<br>
> Before: "Name": "Dump LogService"<br>
> After: "Name": "FaultLog Dump LogService"<br>
><br>
> Example from /redfish/v1/Managers/bmc/LogServices/Dump:<br>
> Before: "Name": "Dump LogService"<br>
> After: "Name": "BMC Dump LogService"<br>
><br>
> Example from /redfish/v1/Systems/system/LogServices/Dump:<br>
> Before: "Name": "Dump LogService"<br>
> After: "Name": "System Dump LogService"<br>
><br>
> 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"?<br>
><br>
> ---<br>
> Details on the reasoning for changing to a more specific name:<br>
><br>
> 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.)<br>
><br>
> 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."<br>
><br>
> 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.<br>
> 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.<br>
<br>
Please open a discussion in a DMTF forum to discuss this.  Not finding<br>
a statement would imply that there's something that needs to be<br>
changed in the redfish specification itself.<br>
<br>
><br>
> 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.<br>
<br>
Lets get clarification from the standards body on how this feature is<br>
intended to work (I believe there's already some discussion going on)<br>
and go from there.  Depending on what the decision is, we can decide<br>
what the next steps are, but as proposed, this would make the "Name"<br>
field part of the unchangeable API.  When we've hit this issue before<br>
in the case of sensors, we ended up making it a system-specific<br>
decision.  I'm not sure that's the right approach here.<br>
<br>
As an added comment, there are more than just OpenBMC systems out<br>
there running Redfish, so if we actually want to use the Name field<br>
for this purpose, it would need prefixed with "OpenBMC" to<br>
differentiate it from other types of logs with similar naming.<br>
<br>
><br>
> Best Regards,<br>
> Claire Weinan<br>
> --<br>
><br>
> Claire Weinan<br>
> Software Engineer<br>
> <a href="mailto:cweinan@google.com" target="_blank">cweinan@google.com</a><br>
</blockquote></div>
</blockquote></div>