Redfish Dump Service Proposal

[Brad Bishop]

> 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