SOL Logging

Rebecca Broekhuis beccabroek at gmail.com
Thu Aug 30 06:08:53 AEST 2018


>The downside of that is the large amount of backlog to be transferred at
>the start of the console session, which is typically when you need the
>current data the most. In most cases, this could just be stale data from
>a previous boot. Because of this, I think it'll be a net *loss* in
>usability.

I was looking at how AMI and supermicro's console works in the UI, and when
the console session is started
it is pre populated with just 30 or so log messages, nothing more. Would it
be possible to combine both channels, replaying only the N most recent log
statements?
I may be misunderstanding what is possible here.

I am also wondering if an implementation like this:
 a) is adequate
 b) would be a net gain in usability (considering the amount of backlog to
be transferred at the start of the session would be smaller)

Becca

On Wed, Aug 29, 2018 at 6:37 AM Alexander Amelkin <a.amelkin at yadro.com>
wrote:

>
> 25.08.2018 00:02, Tanous, Ed wrote:
>
> I would like to start a discussion around the feature of SOL logging, and
> how to best implement it.
>
>
>
> There is a proposal here
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-webui/+/12063/
> that proposes dumping the SOL console text buffer from Javascript into a
> file, and presenting it to the user as a download.  On its face, it seems
> to work as designed.  This has some pretty severe limitations, in that you
> can only dump the console log from your session, and your session is
> essentially destroyed when you switch pages in the webui, or hit refresh.
> I think this is overly limiting, and of the production BMC stacks that I
> know of, none of them implement SOL logging in this way.
>
>
>
> Instead, other BMCs implement it as a circular buffer inside the BMC
> itself, which allows SOL to log data all the time, not just while the user
> is logged in.  I think architecting it this way would be much more useful
> for admins consuming OpenBMC, and make us more useful as a solution.  Doing
> it this way also can make the SOL log available to IPMI and Redfish, as
> well as a file download, which improves the usability quite a bit.  Most
> places I see the SOL logging requested is for audit type purposes, which
> the javascript based version can’t do.
>
>
>
> I’m looking for feedback from the community here.  As written, I don’t
> think the javascript console export is a useful feature given its
> limitations.  Do others agree?  Am I off base?  Are there use models where
> having a log of only the current session is useful?  Should we document the
> limitations so we can respond to bugs in the future?
>
>
>
> That's exactly what we have implemented in our BMC for YADRO VESNIN.
> We have a circular buffer that constantly logs host console output and
> also preserves the first several pages of each host boot. That way we
> always have the last host boot "dmesg" as well as the very last few pages
> before the host dies (or the logs were gathered).
>
> Alexander.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180829/192a1f47/attachment.html>


More information about the openbmc mailing list