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 at 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 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.
>> 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.