All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hanley <rhanley@google.com>
To: Devender Rao <devenrao@in.ibm.com>
Cc: ratagupt@linux.vnet.ibm.com, OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Redfish Dump Service Proposal
Date: Thu, 12 Dec 2019 16:55:48 -0800	[thread overview]
Message-ID: <CAH1kD+YfetwAmGQfjF4ytCQYhhaEorgdiA5svwjm7X91-yG1Tg@mail.gmail.com> (raw)
In-Reply-To: <OF3E82A637.78F050C7-ON002584CE.0025B2F4-002584CE.00271DE9@notes.na.collabserv.com>

[-- 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 --]

  reply	other threads:[~2019-12-13  0:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 11:21 Redfish Dump Service Proposal Ratan Gupta
2019-12-11 11:55 ` Fwd: " Ratan Gupta
2019-12-11 19:13   ` [EXTERNAL] " Neeraj Ladkani
2019-12-12  7:07 ` Devender Rao
2019-12-13  0:55   ` Richard Hanley [this message]
2019-12-13  5:46     ` Jayanth Othayoth
2019-12-13 20:01       ` Bills, Jason M
2019-12-14  5:27         ` dhruvaraj S
2019-12-18  3:25           ` dhruvaraj S
2019-12-18 22:38             ` Bills, Jason M
2020-01-07 10:11               ` Ratan Gupta
2020-01-07 20:08                 ` Bills, Jason M
2020-01-09 20:07                   ` Gunnar Mills
2020-01-16 11:01                     ` Ratan Gupta
2020-01-16 15:56                       ` Gunnar Mills
2020-01-16 16:19                         ` Brad Bishop
2020-01-22  8:19                           ` Ratan Gupta
2020-01-08 20:04         ` Brad Bishop
2020-01-08 20:42           ` Bills, Jason M
2020-01-08 23:13             ` Brad Bishop
2020-01-09  9:55               ` Lawniczak, Maciej

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH1kD+YfetwAmGQfjF4ytCQYhhaEorgdiA5svwjm7X91-yG1Tg@mail.gmail.com \
    --to=rhanley@google.com \
    --cc=devenrao@in.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=ratagupt@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.