Redfish Dump Service Proposal

Redfish Dump Service Proposal

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 128 bytes --]

Hi All,

Please find the redfish dump service proposal for the DMTF attached.

Kindly review and provide your inputs.

Ratan




[-- Attachment #2: DumpOffload_DMTF_Proposal.pptx --]
[-- Type: application/vnd.openxmlformats-officedocument.presentationml.presentation, Size: 824637 bytes --]

Fwd: Redfish Dump Service Proposal

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

Hi All,

Last email I sent on the proposal for Redfish Dump service did not get 
delivered due to the attachment size restriction.

I have upload the same onto DMTF. Please take a look into it and provide 
your comments here or on the dmtf forum.

Link: https://members.dmtf.org/apps/org/workgroup/redfish/download.php/91877

Ratan

-------- Forwarded Message --------
Subject: 	Redfish Dump Service Proposal
Date: 	Tue, 10 Dec 2019 16:51:12 +0530
From: 	Ratan Gupta <ratagupt@linux.vnet.ibm.com>
To: 	openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>



Hi All,

Please find the redfish dump service proposal for the DMTF attached.

Kindly review and provide your inputs.

Ratan





[-- Attachment #2: Type: text/html, Size: 2594 bytes --]

RE: [EXTERNAL] Fwd: Redfish Dump Service Proposal

[Neeraj Ladkani]

Can you send external link for folks who are not member of DMTF forum. 

Neeraj

From: openbmc <openbmc-bounces+neladk=microsoft.com@lists.ozlabs.org> On Behalf Of Ratan Gupta
Sent: Wednesday, December 11, 2019 3:56 AM
To: openbmc@lists.ozlabs.org
Subject: [EXTERNAL] Fwd: Redfish Dump Service Proposal

Hi All,

Last email I sent on the proposal for Redfish Dump service did not get delivered due to the attachment size restriction. 

I have upload the same onto DMTF. Please take a look into it and provide your comments here or on the dmtf forum.

Link: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmembers.dmtf.org%2Fapps%2Forg%2Fworkgroup%2Fredfish%2Fdownload.php%2F91877&data=02%7C01%7Cneladk%40microsoft.com%7Cde774b4f15dd475e4cdb08d77e313124%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116622056042507&sdata=AeXxqmNX5E3UaXApSPh%2B9XuXCELOHXu7gINH66%2Fq%2B64%3D&reserved=0

Ratan

-------- Forwarded Message -------- 
Subject: 
Redfish Dump Service Proposal
Date: 
Tue, 10 Dec 2019 16:51:12 +0530
From: 
Ratan Gupta mailto:ratagupt@linux.vnet.ibm.com
To: 
mailto:openbmc@lists.ozlabs.org mailto:openbmc@lists.ozlabs.org


Hi All,

Please find the redfish dump service proposal for the DMTF attached.

Kindly review and provide your inputs.

Ratan

Re: Redfish Dump Service Proposal

[Devender Rao]

[-- Attachment #1: Type: text/html, Size: 2028 bytes --]

Re: Redfish Dump Service Proposal

[Richard Hanley]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

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 in the
Dump resource that points to the raw dump file.  Then clients can do a
normal HTTP get on that URL.

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.

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.

Regards,
Richard

On Wed, Dec 11, 2019 at 11:08 PM Devender Rao <devenrao@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"
>
> 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@linux.vnet.ibm.com>
> Sent by: "openbmc" <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org>
> To: "openbmc@lists.ozlabs.org" <openbmc@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
>
>
>
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4073 bytes --]

Re: Redfish Dump Service Proposal

[Jayanth Othayoth]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

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@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 in the
> Dump resource that points to the raw dump file.  Then clients can do a
> normal HTTP get on that URL.
>
> 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.
>

> 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.
>
> Regards,
> Richard
>
> On Wed, Dec 11, 2019 at 11:08 PM Devender Rao <devenrao@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"
>>
>> 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@linux.vnet.ibm.com>
>> Sent by: "openbmc" <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org>
>> To: "openbmc@lists.ozlabs.org" <openbmc@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
>>
>>
>>
>>
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 5300 bytes --]

Re: 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@google.com 
> <mailto:rhanley@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@in.ibm.com
>     <mailto:devenrao@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@linux.vnet.ibm.com
>             <mailto:ratagupt@linux.vnet.ibm.com>>
>             Sent by: "openbmc"
>             <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
>             <mailto:in.ibm.com@lists.ozlabs.org>>
>             To: "openbmc@lists.ozlabs.org
>             <mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org
>             <mailto:openbmc@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
> 
> 
> 

Re: Redfish Dump Service Proposal

[dhruvaraj S]

Few comments..

On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
<jason.m.bills@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@google.com
> > <mailto:rhanley@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@in.ibm.com
> >     <mailto:devenrao@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@linux.vnet.ibm.com
> >             <mailto:ratagupt@linux.vnet.ibm.com>>
> >             Sent by: "openbmc"
> >             <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
> >             <mailto:in.ibm.com@lists.ozlabs.org>>
> >             To: "openbmc@lists.ozlabs.org
> >             <mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org
> >             <mailto:openbmc@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

Re: Redfish Dump Service Proposal

[dhruvaraj S]

Hi,

I have an additional comment on creating the dump, there are some
dumps which can take longer than an hour on certain systems and BMC
has no control over its execution. Can we have an additional interface
similar to approach 2 in creating a user-initiated dump named
'Initiate Dump'? Which just initiate the dump asynchronously, without
returning an ID, and such dump will get generated at a later time and
a redfish resource for that dump will be created after the generation.

lPOST https://${bmc_ip}/redfish/v1/DumpService/Actions/InitiateDump
dumpType=BMC/Host/<or a different type>

The main difference from approach 2 in CreateDump is, no redfish
resource for the dump will be created after initiating but only after
the system generated the dump.

On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> wrote:
>
> Few comments..
>
> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
> <jason.m.bills@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@google.com
> > > <mailto:rhanley@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@in.ibm.com
> > >     <mailto:devenrao@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@linux.vnet.ibm.com
> > >             <mailto:ratagupt@linux.vnet.ibm.com>>
> > >             Sent by: "openbmc"
> > >             <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
> > >             <mailto:in.ibm.com@lists.ozlabs.org>>
> > >             To: "openbmc@lists.ozlabs.org
> > >             <mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org
> > >             <mailto:openbmc@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



-- 
--------------
Dhruvaraj S

Re: Redfish Dump Service Proposal

[Bills, Jason M]

On 12/17/2019 7:25 PM, dhruvaraj S wrote:
> Hi,
> 
> I have an additional comment on creating the dump, there are some
> dumps which can take longer than an hour on certain systems and BMC
> has no control over its execution. Can we have an additional interface
> similar to approach 2 in creating a user-initiated dump named
> 'Initiate Dump'? Which just initiate the dump asynchronously, without
> returning an ID, and such dump will get generated at a later time and
> a redfish resource for that dump will be created after the generation.

I think this is a great example of where TaskService and Task Monitor 
would be used.  The response to the command to generate a dump will 
provide a URI to a Task Monitor that can be queried for status on the dump.

When the dump is completed and the new dump resource has been created, 
the Task Monitor will return the location of the dump.

I'm looking to start working on a Task Service design soon and will 
notify the mailing list before I start.

> 
> lPOST https://${bmc_ip}/redfish/v1/DumpService/Actions/InitiateDump
> dumpType=BMC/Host/<or a different type>
> 
> The main difference from approach 2 in CreateDump is, no redfish
> resource for the dump will be created after initiating but only after
> the system generated the dump.

I agree.  The new Redfish resource should only be created after the dump 
has completed.

> 
> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> wrote:
>>
>> Few comments..
>>
>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>> <jason.m.bills@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@google.com
>>>> <mailto:rhanley@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@in.ibm.com
>>>>      <mailto:devenrao@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@linux.vnet.ibm.com
>>>>              <mailto:ratagupt@linux.vnet.ibm.com>>
>>>>              Sent by: "openbmc"
>>>>              <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
>>>>              <mailto:in.ibm.com@lists.ozlabs.org>>
>>>>              To: "openbmc@lists.ozlabs.org
>>>>              <mailto:openbmc@lists.ozlabs.org>" <openbmc@lists.ozlabs.org
>>>>              <mailto:openbmc@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
> 
> 
> 

Re: Redfish Dump Service Proposal

[Ratan Gupta]

Hi All,

Thanks for the responses, Please find my comments inline.

Ratan

On 19/12/19 4:08 AM, Bills, Jason M wrote:
>
>
> On 12/17/2019 7:25 PM, dhruvaraj S wrote:
>> Hi,
>>
>> I have an additional comment on creating the dump, there are some
>> dumps which can take longer than an hour on certain systems and BMC
>> has no control over its execution. Can we have an additional interface
>> similar to approach 2 in creating a user-initiated dump named
>> 'Initiate Dump'? Which just initiate the dump asynchronously, without
>> returning an ID, and such dump will get generated at a later time and
>> a redfish resource for that dump will be created after the generation.
Dhruvaraj,
With approach 2(Task based approach) we would return the task ID and not 
the dump resource ID. Hence I do not see a need to reinvent a new action.

Following is the flow in a task based approach which will also work for 
your mentioned scenario
=> User initiates the dump
=> BMC starts the task and returns the task url to the client
=> Once the task is completed, BMC sends the redfish notification(task 
completed) to the client
=> Client fires the GET request on the task to get the details of the task
=> Task should tell the dump resource ID of the created dump
https://redfish.dmtf.org/schemas/Task.v1_4_2.json
We can use TargetUri under the payload property of the task for the 
generated dump resource URL.
Please note, mapping of a Task Id to the Dump Id/Log entry Id is 
internal to the implementation.
>
> I think this is a great example of where TaskService and Task Monitor 
> would be used.  The response to the command to generate a dump will 
> provide a URI to a Task Monitor that can be queried for status on the 
> dump.
>
> When the dump is completed and the new dump resource has been created, 
> the Task Monitor will return the location of the dump.
>
> I'm looking to start working on a Task Service design soon and will 
> notify the mailing list before I start.
>
Thanks Jason, It is good to hear that you are starting the design for 
Task Service.
>>
>> lPOST https://${bmc_ip}/redfish/v1/DumpService/Actions/InitiateDump
>> dumpType=BMC/Host/<or a different type>
>>
>> The main difference from approach 2 in CreateDump is, no redfish
>> resource for the dump will be created after initiating but only after
>> the system generated the dump.
>
> I agree.  The new Redfish resource should only be created after the 
> dump has completed.

Jason,

I am fine with it, I have proposed the flow above for the task based 
approach.
What is your view where redfish resource has been created and the state 
of the resource tells that the resource is not in ready state or 
downladable.
Get Operation on the resource would be supported which will get the high 
level detail(size,state etc) of the Dump Resource but the dump can be 
downloaded through the download action.
>
>>
>> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> 
>> wrote:
>>>
>>> Few comments..
>>>
>>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>>> <jason.m.bills@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.
Sure we can enhance the type of dump, it is enum in the proposal which 
can be enhanced.
What could be other dump type which I can add in the types?
>>>>
>>>> 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@google.com
>>>>> <mailto:rhanley@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.
Richard,

It makes sense to remove the download action from the dump resource and 
use the odata.id which points to the raw dump file.
Not having dump service as root and putting the dumps under logservice, 
do we want to say some thing like below
/redfish/v1/LogService/entries/<id>
and now the odata.id of log entry would point to the raw dump resource 
file if the type of the log entry is "dump".
Now if it is correct then in that case the log entries would be pointing 
to each other to show the association of system generated dump with an 
error event.
Apart from this as we may have multiple type of dumps then in that we 
need to enhance the log entry to specify the type of dump.
>>>>
>>>>>
>>>>>      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@in.ibm.com
>>>>>      <mailto:devenrao@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@linux.vnet.ibm.com
>>>>> <mailto:ratagupt@linux.vnet.ibm.com>>
>>>>>              Sent by: "openbmc"
>>>>> <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
>>>>> <mailto:in.ibm.com@lists.ozlabs.org>>
>>>>>              To: "openbmc@lists.ozlabs.org
>>>>>              <mailto:openbmc@lists.ozlabs.org>" 
>>>>> <openbmc@lists.ozlabs.org
>>>>>              <mailto:openbmc@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
>>
>>
>>

Re: Redfish Dump Service Proposal

[Bills, Jason M]

On 1/7/2020 2:11 AM, Ratan Gupta wrote:
> Hi All,
> 
> Thanks for the responses, Please find my comments inline.
> 
> Ratan
> 
> On 19/12/19 4:08 AM, Bills, Jason M wrote:
>>
>>
>> On 12/17/2019 7:25 PM, dhruvaraj S wrote:
>>> Hi,
>>>
>>> I have an additional comment on creating the dump, there are some
>>> dumps which can take longer than an hour on certain systems and BMC
>>> has no control over its execution. Can we have an additional interface
>>> similar to approach 2 in creating a user-initiated dump named
>>> 'Initiate Dump'? Which just initiate the dump asynchronously, without
>>> returning an ID, and such dump will get generated at a later time and
>>> a redfish resource for that dump will be created after the generation.
> Dhruvaraj,
> With approach 2(Task based approach) we would return the task ID and not 
> the dump resource ID. Hence I do not see a need to reinvent a new action.
> 
> Following is the flow in a task based approach which will also work for 
> your mentioned scenario
> => User initiates the dump
> => BMC starts the task and returns the task url to the client
> => Once the task is completed, BMC sends the redfish notification(task 
> completed) to the client
> => Client fires the GET request on the task to get the details of the task
> => Task should tell the dump resource ID of the created dump
> https://redfish.dmtf.org/schemas/Task.v1_4_2.json
> We can use TargetUri under the payload property of the task for the 
> generated dump resource URL.
> Please note, mapping of a Task Id to the Dump Id/Log entry Id is 
> internal to the implementation.
>>
>> I think this is a great example of where TaskService and Task Monitor 
>> would be used.  The response to the command to generate a dump will 
>> provide a URI to a Task Monitor that can be queried for status on the 
>> dump.
>>
>> When the dump is completed and the new dump resource has been created, 
>> the Task Monitor will return the location of the dump.
>>
>> I'm looking to start working on a Task Service design soon and will 
>> notify the mailing list before I start.
>>
> Thanks Jason, It is good to hear that you are starting the design for 
> Task Service.
>>>
>>> lPOST https://${bmc_ip}/redfish/v1/DumpService/Actions/InitiateDump
>>> dumpType=BMC/Host/<or a different type>
>>>
>>> The main difference from approach 2 in CreateDump is, no redfish
>>> resource for the dump will be created after initiating but only after
>>> the system generated the dump.
>>
>> I agree.  The new Redfish resource should only be created after the 
>> dump has completed.
> 
> Jason,
> 
> I am fine with it, I have proposed the flow above for the task based 
> approach.
> What is your view where redfish resource has been created and the state 
> of the resource tells that the resource is not in ready state or 
> downladable.
> Get Operation on the resource would be supported which will get the high 
> level detail(size,state etc) of the Dump Resource but the dump can be 
> downloaded through the download action.

Ratan,

I don't think we should create any resources until the log is completed. 
  I don't think the resource info such as size will be very useful until 
it's ready and would add complexity to support.

>>
>>>
>>> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> 
>>> wrote:
>>>>
>>>> Few comments..
>>>>
>>>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>>>> <jason.m.bills@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.
> Sure we can enhance the type of dump, it is enum in the proposal which 
> can be enhanced.
> What could be other dump type which I can add in the types?

I don't have anything specific in mind, but it's possible that there 
would be multiple different types of dumps from the Host and BMC.  For 
example, the BMC might capture a different dump for a Host PCIe error 
vs. a Host Memory error.  Or would both of those be a Host type since 
that is where the data is from?

>>>>>
>>>>> 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@google.com
>>>>>> <mailto:rhanley@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.
> Richard,
> 
> It makes sense to remove the download action from the dump resource and 
> use the odata.id which points to the raw dump file.
> Not having dump service as root and putting the dumps under logservice, 
> do we want to say some thing like below
> /redfish/v1/LogService/entries/<id>
> and now the odata.id of log entry would point to the raw dump resource 
> file if the type of the log entry is "dump".
> Now if it is correct then in that case the log entries would be pointing 
> to each other to show the association of system generated dump with an 
> error event.
> Apart from this as we may have multiple type of dumps then in that we 
> need to enhance the log entry to specify the type of dump.

Internally we have discussed proposing this type of enhancement to 
LogEntry to provide support for this service.

>>>>>
>>>>>>
>>>>>>      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@in.ibm.com
>>>>>>      <mailto:devenrao@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@linux.vnet.ibm.com
>>>>>> <mailto:ratagupt@linux.vnet.ibm.com>>
>>>>>>              Sent by: "openbmc"
>>>>>> <openbmc-bounces+devenrao=in.ibm.com@lists.ozlabs.org
>>>>>> <mailto:in.ibm.com@lists.ozlabs.org>>
>>>>>>              To: "openbmc@lists.ozlabs.org
>>>>>>              <mailto:openbmc@lists.ozlabs.org>" 
>>>>>> <openbmc@lists.ozlabs.org
>>>>>>              <mailto:openbmc@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
>>>
>>>
>>>
> 

Re: Redfish Dump Service Proposal

[Gunnar Mills]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

A couple comments.

On 1/7/2020 2:08 PM, Bills, Jason M wrote:
>
> On 1/7/2020 2:11 AM, Ratan Gupta wrote:
>
>>>
>>>>
>>>> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> 
>>>> wrote:
>>>>>
>>>>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>>>>> <jason.m.bills@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.
>> Sure we can enhance the type of dump, it is enum in the proposal 
>> which can be enhanced.
>> What could be other dump type which I can add in the types?

Slide 15:  Since DumpType is an enum, should reason be as well? "Type" 
is a pretty typical enum in Redfish. E.g. BaseModuleType from 
https://redfish.dmtf.org/schemas/Memory.v1_8_0.json

Reason seems similar to the LogEntryCode from 
https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json

Slide 15:
"Size": 108944B
Redfish size properties typically have the unit in the name. E.g. From 
https://redfish.dmtf.org/schemas/Memory.v1_8_0.json CacheSizeMiB or 
CapacityMiB.

odata.context is getting dropped. See 
https://github.com/DMTF/Redfish/issues/2722 or 
https://github.com/DMTF/Redfish/commit/ae49f4fb1278fd435f89317c3fa53cac597e3893#diff-e82b4876efbeaa600d3b104a426f7ac5 



[-- Attachment #2: Type: text/html, Size: 3734 bytes --]

Re: Redfish Dump Service Proposal

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 4723 bytes --]

Hi All,


Further to the previous dump proposal, I have incorporated the following 
changes.

  * Having seprate LogService redfish resource for each type of dump.

  * Enhance the
    LogService(_https://redfish.dmtf.org/schemas/LogService.v1_1_3.json_)
    property

        "LogEntryType": {

             "enum": [
                       "Event",
                       "SEL",
                       "Oem"
“*Dump*”
                 ] }

  * Enhance the LogService under OEM for further subsystem type

       eg: hostboot dump, hypervisor dump

         “OEM”: {

               “*SystemType*”: { “enum” : [“HostBoot, Hypervisor, etc”] }

                 }

  * Enhance the Log Service for the following
    *Properties*:

     1. *DumpOverridePolicy : **This can be different for all different
        type of dumps.*
     2. **MaxDumps: This can be different for all different type of dumps.**

*Actions:*

     1. *CreateLog:**If logservice (**LogEntryType **is Dump) and the
        subsystem type is “Hypervisor” then create log will create a
        Host hypervisor dump.*
     2. ***DeleteAll: Delete all the logs from this log service, This is
        a addition on the deletion of the single resource(LogEntry).*

  * Enhance the logentry*(*_*https://redfi*
    <https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json>__*sh.dmtf.org/schemas/LogEntry.v1_5_0.json*
    <https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json>_*)*

        "LogEntryType": {
             "enum": [
                       "Event",
                       "SEL",
                       "Oem"
“*Dump*”
                 ] }

  * Map the proposed dump properties with existing log entry property
      o Proposed Property           Existing LogEntry Property
          + ID                          ID
          + Timestamp                   Created
          + Reason                      LogEntryCode(Introduce more
            enums in the LogEntry Code for the
            dump                         reason)

  * New Properties to be introduced in the logEntry
      o *Size*
      o *NOTE: *Dump type is not needed as the logservice logentry type
        will tell that this service is for dump and the system type will
        tell that this service is for which subsytem.

*NOTE: *

*1/ OdataID of log entry redfish resourc**e**will point to the raw dump 
file which can be used to offload the dump.*

*2/ CreateLog: **spawns a task and returns the taskID.Client can query 
the status for the task.*


Please let me know if I have missed something else.I would be making the 
change in the PPT also.

Regards

Ratan Gupta

On 10/01/20 1:37 AM, Gunnar Mills wrote:
>
> A couple comments.
>
> On 1/7/2020 2:08 PM, Bills, Jason M wrote:
>>
>> On 1/7/2020 2:11 AM, Ratan Gupta wrote:
>>
>>>>
>>>>>
>>>>> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S <dhruvaraj@gmail.com> 
>>>>> wrote:
>>>>>>
>>>>>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>>>>>> <jason.m.bills@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.
>>> Sure we can enhance the type of dump, it is enum in the proposal 
>>> which can be enhanced.
>>> What could be other dump type which I can add in the types?
>
> Slide 15:  Since DumpType is an enum, should reason be as well? "Type" 
> is a pretty typical enum in Redfish. E.g. BaseModuleType from 
> https://redfish.dmtf.org/schemas/Memory.v1_8_0.json
>
> Reason seems similar to the LogEntryCode from 
> https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json
>
> Slide 15:
> "Size": 108944B
> Redfish size properties typically have the unit in the name. E.g. From 
> https://redfish.dmtf.org/schemas/Memory.v1_8_0.json CacheSizeMiB or 
> CapacityMiB.
>
> odata.context is getting dropped. See 
> https://github.com/DMTF/Redfish/issues/2722 or 
> https://github.com/DMTF/Redfish/commit/ae49f4fb1278fd435f89317c3fa53cac597e3893#diff-e82b4876efbeaa600d3b104a426f7ac5 
>
>

[-- Attachment #2: Type: text/html, Size: 10740 bytes --]

Re: Redfish Dump Service Proposal

[Gunnar Mills]

[-- Attachment #1: Type: text/plain, Size: 5245 bytes --]


On 1/16/2020 5:01 AM, Ratan Gupta wrote:
>
> Hi All,
>
>
> Further to the previous dump proposal, I have incorporated the 
> following changes.
>
>   * Having seprate LogService redfish resource for each type of dump.
>
>   * Enhance the
>     LogService(_https://redfish.dmtf.org/schemas/LogService.v1_1_3.json_)
>     property
>
>        "LogEntryType": {
>
>             "enum": [
>                       "Event",
>                       "SEL",
>                       "Oem"
> “*Dump*”
>                 ] }
>
>   * Enhance the LogService under OEM for further subsystem type
>
>       eg: hostboot dump, hypervisor dump
>
>         “OEM”: {
>
>               “*SystemType*”: { “enum” : [“HostBoot, Hypervisor, etc”] }
>
>                 }
>
>   * Enhance the Log Service for the following
>     *Properties*:
>
>      1. *DumpOverridePolicy : **This can be different for all
>         different type of dumps.*
>

LogService has a OverWritePolicy property, can we use that?


>      1. **MaxDumps: This can be different for all different type of
>         dumps.**
>
LogService has a MaxNumberOfRecords can we use that and drop this?


>     1.
>
> *Actions:*
>
>      1. *CreateLog:**If logservice (**LogEntryType **is Dump) and the
>         subsystem type is “Hypervisor” then create log will create a
>         Host hypervisor dump.*
>      2. ***DeleteAll: Delete all the logs from this log service, This
>         is a addition on the deletion of the single resource(LogEntry).*
>
LogService has a "ClearLog". Can we use that?


>     1.
>
>
>
>   * Enhance the logentry*(*_*https://redfi*
>     <https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json>__*sh.dmtf.org/schemas/LogEntry.v1_5_0.json*
>     <https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json>_*)*
>
>        "LogEntryType": {
>             "enum": [
>                       "Event",
>                       "SEL",
>                       "Oem"
> “*Dump*”
>                 ] }
>
>   * Map the proposed dump properties with existing log entry property
>       o Proposed Property           Existing LogEntry Property
>           + ID                          ID
>           + Timestamp                   Created
>           + Reason                      LogEntryCode(Introduce more
>             enums in the LogEntry Code for the
>             dump                         reason)
>
>   * New Properties to be introduced in the logEntry
>       o *Size*
>

Redfish size properties typically have the unit in the name.


>       o *NOTE: *Dump type is not needed as the logservice logentry
>         type will tell that this service is for dump and the system
>         type will tell that this service is for which subsytem.
>
> *NOTE: *
>
> *1/ OdataID of log entry redfish resourc**e**will point to the raw 
> dump file which can be used to offload the dump.*
>
> *2/ CreateLog: **spawns a task and returns the taskID.Client can query 
> the status for the task.*
>
>
> Please let me know if I have missed something else.I would be making 
> the change in the PPT also.
>
> Regards
>
> Ratan Gupta
>
> On 10/01/20 1:37 AM, Gunnar Mills wrote:
>>
>> A couple comments.
>>
>> On 1/7/2020 2:08 PM, Bills, Jason M wrote:
>>>
>>> On 1/7/2020 2:11 AM, Ratan Gupta wrote:
>>>
>>>>>
>>>>>>
>>>>>> On Sat, Dec 14, 2019 at 10:57 AM dhruvaraj S 
>>>>>> <dhruvaraj@gmail.com> wrote:
>>>>>>>
>>>>>>> On Sat, Dec 14, 2019 at 1:32 AM Bills, Jason M
>>>>>>> <jason.m.bills@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.
>>>> Sure we can enhance the type of dump, it is enum in the proposal 
>>>> which can be enhanced.
>>>> What could be other dump type which I can add in the types?
>>
>> Slide 15:  Since DumpType is an enum, should reason be as well? 
>> "Type" is a pretty typical enum in Redfish. E.g. BaseModuleType from 
>> https://redfish.dmtf.org/schemas/Memory.v1_8_0.json
>>
>> Reason seems similar to the LogEntryCode from 
>> https://redfish.dmtf.org/schemas/LogEntry.v1_5_0.json
>>
>> Slide 15:
>> "Size": 108944B
>> Redfish size properties typically have the unit in the name. E.g. 
>> From https://redfish.dmtf.org/schemas/Memory.v1_8_0.json CacheSizeMiB 
>> or CapacityMiB.
>>
>> odata.context is getting dropped. See 
>> https://github.com/DMTF/Redfish/issues/2722 or 
>> https://github.com/DMTF/Redfish/commit/ae49f4fb1278fd435f89317c3fa53cac597e3893#diff-e82b4876efbeaa600d3b104a426f7ac5 
>>
>>

[-- Attachment #2: Type: text/html, Size: 12685 bytes --]

Re: Redfish Dump Service Proposal

[Brad Bishop]

> On Jan 16, 2020, at 10:56 AM, Gunnar Mills <gmills@linux.vnet.ibm.com> wrote:
>> On 1/16/2020 5:01 AM, Ratan Gupta wrote:
>> 
>> 	• New Properties to be introduced in the logEntry
>> 		• Size
> 
> Redfish size properties typically have the unit in the name.

I wonder if a client could do a HEAD and just check the returned content-length?

Re: Redfish Dump Service Proposal

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

Hi All,

Please find the presentation attached with the comments incorporated.

Ratan


On 16/01/20 9:49 PM, Brad Bishop wrote:
>
>> On Jan 16, 2020, at 10:56 AM, Gunnar Mills <gmills@linux.vnet.ibm.com> wrote:
>>> On 1/16/2020 5:01 AM, Ratan Gupta wrote:
>>>
>>> 	• New Properties to be introduced in the logEntry
>>> 		• Size
>> Redfish size properties typically have the unit in the name.
> I wonder if a client could do a HEAD and just check the returned content-length?

[-- Attachment #2: DumpOffload_DMTF_Proposal_v2.pptx --]
[-- Type: application/vnd.openxmlformats-officedocument.presentationml.presentation, Size: 804804 bytes --]

Re: Redfish Dump Service Proposal

[Brad Bishop]

> On Dec 13, 2019, at 3:01 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
> 
> I like this as well.  I'm trying to support a CPU crashdump that would fit perfectly with this proposal.

Hi Jason

Could you say a few words about how your crash dump service works?  I’m asking because Dhruv is working on an implementation of this proposal:

https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28260

Right now it looks pretty POWER-centric but depending on how your code works I’m wondering which makes more sense:

1 - a single implementation with —-enable-power —-enable-x86 type configure options.

-or-

2 - two completely different implementations with the same dbus interfaces.

thoughts?

Re: Redfish Dump Service Proposal

[Bills, Jason M]

On 1/8/2020 12:04 PM, Brad Bishop wrote:
> 
> 
>> On Dec 13, 2019, at 3:01 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
>>
>> I like this as well.  I'm trying to support a CPU crashdump that would fit perfectly with this proposal.
> 
> Hi Jason
> 
> Could you say a few words about how your crash dump service works?  I’m asking because Dhruv is working on an implementation of this proposal:

Sure.

I have a service called host-error-monitor that watches for error 
signals from the host.  When a CPU fatal error occurs, the 
host-error-monitor triggers a crashdump from the crashdump service.

The crashdump service itself is very minimal today.  It has two trigger 
methods on DBus.  One is to trigger a log for a real error that may need 
to be stored on the BMC.  The other is to trigger a manual log that does 
not need to persist.

When triggered, the BMC reads the crash data from the CPU using PECI. 
After a log has been completed, it is added to DBus as a new object with 
a 'Log' property which holds the contents of the log as a string.

The host-error-monitor source is shared here: 
https://github.com/Intel-BMC/host-error-monitor.
The crashdump source is not currently licensed for public access.

> 
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28260
> 
> Right now it looks pretty POWER-centric but depending on how your code works I’m wondering which makes more sense:
> 
> 1 - a single implementation with —-enable-power —-enable-x86 type configure options.
> 
> -or-
> 
> 2 - two completely different implementations with the same dbus interfaces.
I think this is probably the simplest approach.  It will allow us to 
standardize the Redfish interface without worrying about the actual log 
collection.

I also think we can move from this toward option 1 if we find a lot of 
commonalities in the future.

> 
> thoughts?
> 

Re: Redfish Dump Service Proposal

[Brad Bishop]

> On Jan 8, 2020, at 3:42 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
> 
> 
> 
> On 1/8/2020 12:04 PM, Brad Bishop wrote:
>>> On Dec 13, 2019, at 3:01 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
>>> 
>>> I like this as well.  I'm trying to support a CPU crashdump that would fit perfectly with this proposal.
>> Hi Jason
>> Could you say a few words about how your crash dump service works?  I’m asking because Dhruv is working on an implementation of this proposal:
> 
> Sure.
> 
> I have a service called host-error-monitor that watches for error signals from the host.  When a CPU fatal error occurs, the host-error-monitor triggers a crashdump from the crashdump service.
> 
> The crashdump service itself is very minimal today.  It has two trigger methods on DBus.  One is to trigger a log for a real error that may need to be stored on the BMC.  The other is to trigger a manual log that does not need to persist.
> 
> When triggered, the BMC reads the crash data from the CPU using PECI. After a log has been completed, it is added to DBus as a new object with a 'Log' property which holds the contents of the log as a string.
> 
> The host-error-monitor source is shared here: https://github.com/Intel-BMC/host-error-monitor.
> The crashdump source is not currently licensed for public access.

Thanks for sharing!

> 
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28260
>> Right now it looks pretty POWER-centric but depending on how your code works I’m wondering which makes more sense:
>> 1 - a single implementation with —-enable-power —-enable-x86 type configure options.
>> -or-
>> 2 - two completely different implementations with the same dbus interfaces.
> I think this is probably the simplest approach.  It will allow us to standardize the Redfish interface without worrying about the actual log collection.

Ok, sounds good.  If you are able to find the time it would be good if you could look at Dhruvs proposal just from a DBus interface perspective.  That way we all don’t have to deal with two different DBus data models for gathering dumps in bmcweb when you end up implementing the x86 version.

> 
> I also think we can move from this toward option 1 if we find a lot of commonalities in the future.

Awesome!

thx - brad

RE: Redfish Dump Service Proposal

[Lawniczak, Maciej]

Hi guys,

Few remarks on below topic.

Current solution will not allow for configuration of specific dump applications e.g.:
- number of dumps stored - this can differ between each dump types (we can set higher limit for smaller dumps and smaller for big ones)
- type of data gathered - in some use cases type of trigger defines what kind of data should be gathered. Correlation between trigger and data gathered can be configurable.
- triggers to start dump collection - user should have an option to set which kind of triggers will cause dump collection

Dump Service could be collection of device specific dump services each with its own configuration.
These configuration options (and maybe others) could be included in configuration part of each specific dump service.

Type of Dump as an enum field can bring some challenges because there will be more devices in future that we will be able to collect dumps from.
Changing this field in DMTF every time for new device type will add extra work on both OpenBMC and DMTF side.
Is there a reason why this field could not be a string? We will still use some basic types as Host or BMC but it will allow to add dumps from different platform components easily.

Regards,
Maciej

> On Jan 8, 2020, at 3:42 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
> 
> 
> 
> On 1/8/2020 12:04 PM, Brad Bishop wrote:
>>> On Dec 13, 2019, at 3:01 PM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
>>> 
>>> I like this as well.  I'm trying to support a CPU crashdump that would fit perfectly with this proposal.
>> Hi Jason
>> Could you say a few words about how your crash dump service works?  I’m asking because Dhruv is working on an implementation of this proposal:
> 
> Sure.
> 
> I have a service called host-error-monitor that watches for error signals from the host.  When a CPU fatal error occurs, the host-error-monitor triggers a crashdump from the crashdump service.
> 
> The crashdump service itself is very minimal today.  It has two trigger methods on DBus.  One is to trigger a log for a real error that may need to be stored on the BMC.  The other is to trigger a manual log that does not need to persist.
> 
> When triggered, the BMC reads the crash data from the CPU using PECI. After a log has been completed, it is added to DBus as a new object with a 'Log' property which holds the contents of the log as a string.
> 
> The host-error-monitor source is shared here: https://github.com/Intel-BMC/host-error-monitor.
> The crashdump source is not currently licensed for public access.

Thanks for sharing!

> 
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28260
>> Right now it looks pretty POWER-centric but depending on how your code works I’m wondering which makes more sense:
>> 1 - a single implementation with —-enable-power —-enable-x86 type configure options.
>> -or-
>> 2 - two completely different implementations with the same dbus interfaces.
> I think this is probably the simplest approach.  It will allow us to standardize the Redfish interface without worrying about the actual log collection.

Ok, sounds good.  If you are able to find the time it would be good if you could look at Dhruvs proposal just from a DBus interface perspective.  That way we all don’t have to deal with two different DBus data models for gathering dumps in bmcweb when you end up implementing the x86 version.

> 
> I also think we can move from this toward option 1 if we find a lot of commonalities in the future.

Awesome!

thx - brad
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.