Redfish Dump Service Proposal
Bills, Jason M
jason.m.bills at linux.intel.com
Wed Jan 8 07:08:33 AEDT 2020
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 at gmail.com>
>>> wrote:
>>>>
>>>> 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.
> 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 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.
> 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 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