Seek feedback: BMC console and debug info

Seek feedback: BMC console and debug info

[Zhenfei Tai]

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

Hi,

We have worked with our vendor on a system that provides console and debug
information, which can be useful in times of debugging BMC issues.

On a high level, we use obmc-console
<https://github.com/openbmc/obmc-console> and phosphor-debug-collector
<https://github.com/openbmc/phosphor-debug-collector> to collect data.

   - obmc-console: We collect console inputs from the *host* and save to
   local log files (max 8 files of 1 MB size with rotation.)
   - phosphor-debug-collector: We run this process on the BMC with no
   modification.

For the interface, the data is exposed via bmcweb where there are a pair of
URIs for console inputs and debug collector respectively.
e.g.

   - /redfish/v1/Systems/system/LogServices/Console -- Enable/disable
   console inputs data collection.
   - /redfish/v1/Systems/system/LogServices/ConsoleDownload -- Download the
   log files in a zipped file.

It will be great if we can get some feedback on whether the community finds
such a system useful and advice to improve the design.

Thanks,
Zhenfei

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

Re: Seek feedback: BMC console and debug info

[Ed Tanous]

Yes, this would be useful to others.  A number of commercial stacks
(including some I helped write) have this feature, and I had hoped
someone would tackle it at some point in the future.

My only comment is I'd rather that we don't duplicate the endpoints in
Redfish, and have both a Console and a ConsoleDownload collection.  If
we need a mechanism to download the full log files, I'd recommend that
the Console endpoint obey an Accept header of "text/plain;
charset=utf-8" and an Accept-Encoding header of "gzip".  That way,
we're still meeting the intent of the HTTP and Redfish specs, even if
we're providing more data download options than they require.

Other than that, yeah, sounds great, lets see the patchset.

-Ed

On Tue, Aug 25, 2020 at 8:24 PM Zhenfei Tai <ztai@google.com> wrote:
>
> Hi,
>
> We have worked with our vendor on a system that provides console and debug information, which can be useful in times of debugging BMC issues.
>
> On a high level, we use obmc-console and phosphor-debug-collector to collect data.
>
> obmc-console: We collect console inputs from the host and save to local log files (max 8 files of 1 MB size with rotation.)
> phosphor-debug-collector: We run this process on the BMC with no modification.
>
> For the interface, the data is exposed via bmcweb where there are a pair of URIs for console inputs and debug collector respectively.
> e.g.
>
> /redfish/v1/Systems/system/LogServices/Console -- Enable/disable console inputs data collection.
> /redfish/v1/Systems/system/LogServices/ConsoleDownload -- Download the log files in a zipped file.
>
> It will be great if we can get some feedback on whether the community finds such a system useful and advice to improve the design.
>
> Thanks,
> Zhenfei

Re: Seek feedback: BMC console and debug info

[Vijay Khemka]

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



From: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on behalf of Zhenfei Tai <ztai@google.com>
Date: Tuesday, August 25, 2020 at 8:24 PM
To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Seek feedback: BMC console and debug info

Hi,

We have worked with our vendor on a system that provides console and debug information, which can be useful in times of debugging BMC issues.

On a high level, we use obmc-console<https://github.com/openbmc/obmc-console> and phosphor-debug-collector<https://github.com/openbmc/phosphor-debug-collector> to collect data.

  *   obmc-console: We collect console inputs from the host and save to local log files (max 8 files of 1 MB size with rotation.)
There is already an application name phosphor-hostlogger which saves console data in a file.

  *   phosphor-debug-collector: We run this process on the BMC with no modification.
For the interface, the data is exposed via bmcweb where there are a pair of URIs for console inputs and debug collector respectively.
e.g.

  *   /redfish/v1/Systems/system/LogServices/Console -- Enable/disable console inputs data collection.
  *   /redfish/v1/Systems/system/LogServices/ConsoleDownload -- Download the log files in a zipped file.
It will be great if we can get some feedback on whether the community finds such a system useful and advice to improve the design.

Thanks,
Zhenfei

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

Re: Seek feedback: BMC console and debug info

[Bills, Jason M]

On 8/25/2020 8:35 PM, Ed Tanous wrote:
> Yes, this would be useful to others.  A number of commercial stacks
> (including some I helped write) have this feature, and I had hoped
> someone would tackle it at some point in the future.
> 
> My only comment is I'd rather that we don't duplicate the endpoints in
> Redfish, and have both a Console and a ConsoleDownload collection.  If
> we need a mechanism to download the full log files, I'd recommend that
> the Console endpoint obey an Accept header of "text/plain;
> charset=utf-8" and an Accept-Encoding header of "gzip".  That way,
> we're still meeting the intent of the HTTP and Redfish specs, even if
> we're providing more data download options than they require.
I still need to go dig into it, but I think the new Redfish schemas that 
were added to support the Dump service, added an "AdditionalDataURI" 
property that can provide a URI to download a larger set of additional 
dump data.  It may be what you need for the log file download.

> 
> Other than that, yeah, sounds great, lets see the patchset.
> 
> -Ed
> 
> On Tue, Aug 25, 2020 at 8:24 PM Zhenfei Tai <ztai@google.com> wrote:
>>
>> Hi,
>>
>> We have worked with our vendor on a system that provides console and debug information, which can be useful in times of debugging BMC issues.
>>
>> On a high level, we use obmc-console and phosphor-debug-collector to collect data.
>>
>> obmc-console: We collect console inputs from the host and save to local log files (max 8 files of 1 MB size with rotation.)
>> phosphor-debug-collector: We run this process on the BMC with no modification.
>>
>> For the interface, the data is exposed via bmcweb where there are a pair of URIs for console inputs and debug collector respectively.
>> e.g.
>>
>> /redfish/v1/Systems/system/LogServices/Console -- Enable/disable console inputs data collection.
>> /redfish/v1/Systems/system/LogServices/ConsoleDownload -- Download the log files in a zipped file.
>>
>> It will be great if we can get some feedback on whether the community finds such a system useful and advice to improve the design.
>>
>> Thanks,
>> Zhenfei

Re: Seek feedback: BMC console and debug info

[Zhenfei Tai]

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

Thanks a lot for the feedback and we're glad that it's something the
community is interested in!
We'll incorporate the advice and improve the patchset.

Jason - If you have time, could you share the findings of the
"AdditionalDataURI" schema change? I've only managed to find some slides
<https://www.dmtf.org/sites/default/files/Redfish_Diagnostic_Data_Logging_Proposal_05-2020-WIP_0.pdf>
from May.

Thanks,
Zhenfei

On Wed, Aug 26, 2020 at 1:00 PM Bills, Jason M <
jason.m.bills@linux.intel.com> wrote:

>
>
> On 8/25/2020 8:35 PM, Ed Tanous wrote:
> > Yes, this would be useful to others.  A number of commercial stacks
> > (including some I helped write) have this feature, and I had hoped
> > someone would tackle it at some point in the future.
> >
> > My only comment is I'd rather that we don't duplicate the endpoints in
> > Redfish, and have both a Console and a ConsoleDownload collection.  If
> > we need a mechanism to download the full log files, I'd recommend that
> > the Console endpoint obey an Accept header of "text/plain;
> > charset=utf-8" and an Accept-Encoding header of "gzip".  That way,
> > we're still meeting the intent of the HTTP and Redfish specs, even if
> > we're providing more data download options than they require.
> I still need to go dig into it, but I think the new Redfish schemas that
> were added to support the Dump service, added an "AdditionalDataURI"
> property that can provide a URI to download a larger set of additional
> dump data.  It may be what you need for the log file download.
>
> >
> > Other than that, yeah, sounds great, lets see the patchset.
> >
> > -Ed
> >
> > On Tue, Aug 25, 2020 at 8:24 PM Zhenfei Tai <ztai@google.com> wrote:
> >>
> >> Hi,
> >>
> >> We have worked with our vendor on a system that provides console and
> debug information, which can be useful in times of debugging BMC issues.
> >>
> >> On a high level, we use obmc-console and phosphor-debug-collector to
> collect data.
> >>
> >> obmc-console: We collect console inputs from the host and save to local
> log files (max 8 files of 1 MB size with rotation.)
> >> phosphor-debug-collector: We run this process on the BMC with no
> modification.
> >>
> >> For the interface, the data is exposed via bmcweb where there are a
> pair of URIs for console inputs and debug collector respectively.
> >> e.g.
> >>
> >> /redfish/v1/Systems/system/LogServices/Console -- Enable/disable
> console inputs data collection.
> >> /redfish/v1/Systems/system/LogServices/ConsoleDownload -- Download the
> log files in a zipped file.
> >>
> >> It will be great if we can get some feedback on whether the community
> finds such a system useful and advice to improve the design.
> >>
> >> Thanks,
> >> Zhenfei
>

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

Re: Seek feedback: BMC console and debug info

[Bills, Jason M]

On 8/29/2020 8:53 PM, Zhenfei Tai wrote:
> Thanks a lot for the feedback and we're glad that it's something the 
> community is interested in!
> We'll incorporate the advice and improve the patchset.
> 
> Jason - If you have time, could you share the findings of the 
> "AdditionalDataURI" schema change? I've only managed to find some slides 
> <https://www.dmtf.org/sites/default/files/Redfish_Diagnostic_Data_Logging_Proposal_05-2020-WIP_0.pdf> 
> from May.
Sorry, I don't know much about it besides that the schema change is 
coming.  I checked on the DMTF website and it doesn't look like the new 
schema has been posted, yet.

> 
> Thanks,
> Zhenfei
> 
> On Wed, Aug 26, 2020 at 1:00 PM Bills, Jason M 
> <jason.m.bills@linux.intel.com <mailto:jason.m.bills@linux.intel.com>> 
> wrote:
> 
> 
> 
>     On 8/25/2020 8:35 PM, Ed Tanous wrote:
>      > Yes, this would be useful to others.  A number of commercial stacks
>      > (including some I helped write) have this feature, and I had hoped
>      > someone would tackle it at some point in the future.
>      >
>      > My only comment is I'd rather that we don't duplicate the
>     endpoints in
>      > Redfish, and have both a Console and a ConsoleDownload
>     collection.  If
>      > we need a mechanism to download the full log files, I'd recommend
>     that
>      > the Console endpoint obey an Accept header of "text/plain;
>      > charset=utf-8" and an Accept-Encoding header of "gzip".  That way,
>      > we're still meeting the intent of the HTTP and Redfish specs, even if
>      > we're providing more data download options than they require.
>     I still need to go dig into it, but I think the new Redfish schemas
>     that
>     were added to support the Dump service, added an "AdditionalDataURI"
>     property that can provide a URI to download a larger set of additional
>     dump data.  It may be what you need for the log file download.
> 
>      >
>      > Other than that, yeah, sounds great, lets see the patchset.
>      >
>      > -Ed
>      >
>      > On Tue, Aug 25, 2020 at 8:24 PM Zhenfei Tai <ztai@google.com
>     <mailto:ztai@google.com>> wrote:
>      >>
>      >> Hi,
>      >>
>      >> We have worked with our vendor on a system that provides console
>     and debug information, which can be useful in times of debugging BMC
>     issues.
>      >>
>      >> On a high level, we use obmc-console and
>     phosphor-debug-collector to collect data.
>      >>
>      >> obmc-console: We collect console inputs from the host and save
>     to local log files (max 8 files of 1 MB size with rotation.)
>      >> phosphor-debug-collector: We run this process on the BMC with no
>     modification.
>      >>
>      >> For the interface, the data is exposed via bmcweb where there
>     are a pair of URIs for console inputs and debug collector respectively.
>      >> e.g.
>      >>
>      >> /redfish/v1/Systems/system/LogServices/Console -- Enable/disable
>     console inputs data collection.
>      >> /redfish/v1/Systems/system/LogServices/ConsoleDownload --
>     Download the log files in a zipped file.
>      >>
>      >> It will be great if we can get some feedback on whether the
>     community finds such a system useful and advice to improve the design.
>      >>
>      >> Thanks,
>      >> Zhenfei
> 

Re: Seek feedback: BMC console and debug info

[Richard Hanley]

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

I've been out of the loop on this for a while. Does anyone know if progress
has been made on the DumpService in DMTF. I remember there were some
proposals a while back, but I can't remember where they left off.

- Richard

On Wed, Sep 2, 2020 at 12:00 PM Bills, Jason M <
jason.m.bills@linux.intel.com> wrote:

>
>
> On 8/29/2020 8:53 PM, Zhenfei Tai wrote:
> > Thanks a lot for the feedback and we're glad that it's something the
> > community is interested in!
> > We'll incorporate the advice and improve the patchset.
> >
> > Jason - If you have time, could you share the findings of the
> > "AdditionalDataURI" schema change? I've only managed to find some slides
> > <
> https://www.dmtf.org/sites/default/files/Redfish_Diagnostic_Data_Logging_Proposal_05-2020-WIP_0.pdf>
>
> > from May.
> Sorry, I don't know much about it besides that the schema change is
> coming.  I checked on the DMTF website and it doesn't look like the new
> schema has been posted, yet.
>
> >
> > Thanks,
> > Zhenfei
> >
> > On Wed, Aug 26, 2020 at 1:00 PM Bills, Jason M
> > <jason.m.bills@linux.intel.com <mailto:jason.m.bills@linux.intel.com>>
> > wrote:
> >
> >
> >
> >     On 8/25/2020 8:35 PM, Ed Tanous wrote:
> >      > Yes, this would be useful to others.  A number of commercial
> stacks
> >      > (including some I helped write) have this feature, and I had hoped
> >      > someone would tackle it at some point in the future.
> >      >
> >      > My only comment is I'd rather that we don't duplicate the
> >     endpoints in
> >      > Redfish, and have both a Console and a ConsoleDownload
> >     collection.  If
> >      > we need a mechanism to download the full log files, I'd recommend
> >     that
> >      > the Console endpoint obey an Accept header of "text/plain;
> >      > charset=utf-8" and an Accept-Encoding header of "gzip".  That way,
> >      > we're still meeting the intent of the HTTP and Redfish specs,
> even if
> >      > we're providing more data download options than they require.
> >     I still need to go dig into it, but I think the new Redfish schemas
> >     that
> >     were added to support the Dump service, added an "AdditionalDataURI"
> >     property that can provide a URI to download a larger set of
> additional
> >     dump data.  It may be what you need for the log file download.
> >
> >      >
> >      > Other than that, yeah, sounds great, lets see the patchset.
> >      >
> >      > -Ed
> >      >
> >      > On Tue, Aug 25, 2020 at 8:24 PM Zhenfei Tai <ztai@google.com
> >     <mailto:ztai@google.com>> wrote:
> >      >>
> >      >> Hi,
> >      >>
> >      >> We have worked with our vendor on a system that provides console
> >     and debug information, which can be useful in times of debugging BMC
> >     issues.
> >      >>
> >      >> On a high level, we use obmc-console and
> >     phosphor-debug-collector to collect data.
> >      >>
> >      >> obmc-console: We collect console inputs from the host and save
> >     to local log files (max 8 files of 1 MB size with rotation.)
> >      >> phosphor-debug-collector: We run this process on the BMC with no
> >     modification.
> >      >>
> >      >> For the interface, the data is exposed via bmcweb where there
> >     are a pair of URIs for console inputs and debug collector
> respectively.
> >      >> e.g.
> >      >>
> >      >> /redfish/v1/Systems/system/LogServices/Console -- Enable/disable
> >     console inputs data collection.
> >      >> /redfish/v1/Systems/system/LogServices/ConsoleDownload --
> >     Download the log files in a zipped file.
> >      >>
> >      >> It will be great if we can get some feedback on whether the
> >     community finds such a system useful and advice to improve the
> design.
> >      >>
> >      >> Thanks,
> >      >> Zhenfei
> >
>

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

Re: Seek feedback: BMC console and debug info

[Gunnar Mills]

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

On 9/2/2020 9:29 PM, Richard Hanley wrote:
> I've been out of the loop on this for a while. Does anyone know if 
> progress has been made on the DumpService in DMTF. I remember there 
> were some proposals a while back, but I can't remember where they left 
> off.
>

Dump/Diagnostic Data will be part of the 2020.3 Redfish Release.
2020.3 should be public in the next week or 2.

There isn't a "DumpService" but instead LogService and LogEntry were 
enhanced to support Dumps.
The merged pull request can be found at 
https://github.com/DMTF/Redfish/pull/3968 (have to be a Redfish member).

It is very similar to the WIP shown below though.

>
> On Wed, Sep 2, 2020 at 12:00 PM Bills, Jason M 
> <jason.m.bills@linux.intel.com <mailto:jason.m.bills@linux.intel.com>> 
> wrote:
>
>
>
>     On 8/29/2020 8:53 PM, Zhenfei Tai wrote:
>     > Thanks a lot for the feedback and we're glad that it's something
>     the
>     > community is interested in!
>     > We'll incorporate the advice and improve the patchset.
>     >
>     > Jason - If you have time, could you share the findings of the
>     > "AdditionalDataURI" schema change? I've only managed to find
>     some slides
>     >
>     <https://www.dmtf.org/sites/default/files/Redfish_Diagnostic_Data_Logging_Proposal_05-2020-WIP_0.pdf>
>
>     > from May.
>     Sorry, I don't know much about it besides that the schema change is
>     coming.  I checked on the DMTF website and it doesn't look like
>     the new
>     schema has been posted, yet.
>

Should be on the DMTF website in the next week or two. :)

Gunnar

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