Redfish Dump Service Proposal

[Bills, Jason M]

I like this as well.  I'm trying to support a CPU crashdump that would 
fit perfectly with this proposal.

A question and some comments below:

Will Dump only have the two types: BMC and Host?  Could this be more 
flexible to allow for multiple different types of dumps from various 
components?

On 12/12/2019 9:46 PM, Jayanth Othayoth wrote:
> 
> Dump is an additional debug data associated  to an error event.
>  From the phosphor-debug-collector  perspective,  BMC Dump collects 
> additional debug information, which canot be contained in the error log. 
> Please find my comments inline.
> 
> On Fri, Dec 13, 2019 at 6:27 AM Richard Hanley <rhanley at google.com 
> <mailto:rhanley at google.com>> wrote:
> 
>     Hi Ratan,
> 
>     I think this service is a really good idea.  A couple of thoughts:
> 
>     1) I don't think the semantics around the Download action are
>     consistent.  Generally actions are reserved for stateful changes,
>     and only have post methods.  I think this could be simplified by
>     putting an @odata.id <http://odata.id> in the Dump resource that
>     points to the raw dump file.  Then clients can do a normal HTTP get
>     on that URL.
I agree.  Currently, I have crashdump as a LogService, so it is very 
easy to list and download the dumps using the standard 
LogService/LogEntry resources.

> 
>     2) I'm wondering what is the best way to communicate what MIME type
>     the raw dump supports.  In theory that could be a part of the
>     RawDump resource.  However, a case could be made that it should be
>     put into the Dump resource.
> 
>     3) Perhaps the dump service should be embedded into other resources,
>     instead of being a top level service.  I'm imagining something like
>     how the LogService is setup.  That way there are a lot fewer
>     dumpTypes for any particular instance of the service.
>         a) This could be taken to the extreme, and the DumpService could
>     be integrated with the existing LogServices.  This would mean adding
>     in a new log type, and having a new action >
>     +Agree with this suggestion to embedding dump under log service as
>     new EventType.  Also need an association  for each system generated
>     dump with an error event.
Yes.  I think it would be better to integrate with the existing 
LogServices.  The existing resources already provide a lot of what is 
needed, so we can leverage that.

The idea that I'm currently using is instead of providing the dump 
content directly in the LogEntry, it provides a URI where the dump can 
be downloaded.  I was thinking of proposing to add a "Uri" property or 
EntryType to LogEntry to support this.  That would allow many different 
types of dump data to be included without having to specify the content 
(similar to how the MessageRegistryFile and JsonSchemaFile resources 
work today, perhaps defining a DumpFile).

With support for LogService, the DumpService would really only need to 
add support for the "Create" action and all logs would be available 
under the corresponding dump LogService.

For the asynchronous create, the Redfish Task Monitor seems like the 
right solution to handle the dump as a long-running task.  That way the 
create command can immediately return and provide the Task Monitor to 
track completion.

In the meantime, I am using the LogService to track when the newly 
created entry becomes available.

> 
> 
>     4) It might be a good idea to have some event support in the cases
>     where a dump is created because of a machine crash.
Wouldn't we also get this by leveraging the LogService?

> 
>     Regards,
>     Richard
> 
>     On Wed, Dec 11, 2019 at 11:08 PM Devender Rao <devenrao at in.ibm.com
>     <mailto:devenrao at in.ibm.com>> wrote:
> 
>         Over all the schema looks good. Few observations for clarity,
>         also how about we have multiple collection say
>         HostDumpCollection, BMCDumpCollection  and also a new service
>         DumpLocations similar to "CertificateLocations"
If we use LogService, each of these collections could just be a separate 
LogService.

> 
>         Page 17: Dump Creation flow
>         1. The time line diagram should show that "Request to create
>         dump" return immediatley. The redfish client will be notififed
>         asynchronously when the dump is collected through DumpCollected
>         event. Request for dump with resource id should be in the same
>         time line when it gets notified of Dump collection completed. >         Page 19: For clarity
>         "List Dumps" should be shown as part of DumpColletion rather
>         than under "Operations on dump"
>         "Get Dump details" should be shown under dump service
>         "Delete Dumps" should be shown under DumpService
> 
>             ----- Original message -----
>             From: Ratan Gupta <ratagupt at linux.vnet.ibm.com
>             <mailto:ratagupt at linux.vnet.ibm.com>>
>             Sent by: "openbmc"
>             <openbmc-bounces+devenrao=in.ibm.com at lists.ozlabs.org
>             <mailto:in.ibm.com at lists.ozlabs.org>>
>             To: "openbmc at lists.ozlabs.org
>             <mailto:openbmc at lists.ozlabs.org>" <openbmc at lists.ozlabs.org
>             <mailto:openbmc at lists.ozlabs.org>>
>             Cc:
>             Subject: [EXTERNAL] Redfish Dump Service Proposal
>             Date: Thu, Dec 12, 2019 5:09 AM
>             Hi All,
> 
>             Please find the redfish dump service proposal for the DMTF
>             attached.
> 
>             Kindly review and provide your inputs.
> 
>             Ratan
> 
> 
>