Redfish Dump Service Proposal
dhruvaraj S
dhruvaraj at gmail.com
Sat Dec 14 16:27:15 AEDT 2019
Few comments..
On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
<jason.m.bills at linux.intel.com> wrote:
>
> 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?
+ I think dump types should be flexible to cover different types of
host or bmc dumps from different components with varying formats.
>
> 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.
+Agree with integrating dump under LogService, The id of the dump can be
unique to dump type, so something like Dumps/<DumpType>/<id>?
>
> 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.
+Yes, for some types of long-running dump tasks, the dump id may not be
available immediately, The response body with the dump id can be returned
once the operation is completed successfully.
>
> 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
> >
> >
> >
--
--------------
Dhruvaraj S
More information about the openbmc
mailing list