SOL Logging

[Emily Shaffer]

I wonder if there's a different and more useful way we can provide the
console scrollback. Thinking about this, it's not just a GUI issue, right -
we deliver our console over TCP to a client elsewhere and would have the
same dedupe issues if we needed to start providing backlog.  Speaking with
almost no experience implementing server-side sockets, is it possible for
us to keep that ring buffer in the console socket as well?

I'm also interested in how you all are getting the console over to webui.
Is it delivered via Redfish? (This is totally different from what we are
doing, so apologies if that's a fundamental question, but I'm certainly
keen to know now :) )

Emily

On Wed, Aug 29, 2018 at 1:09 PM Rebecca Broekhuis <beccabroek at gmail.com>
wrote:

>
> >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/20180904/8e859969/attachment-0001.html>