<div dir="ltr">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?<div><br></div><div>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 :) )</div><div><br></div><div>Emily</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 1:09 PM Rebecca Broekhuis <<a href="mailto:beccabroek@gmail.com">beccabroek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>>The downside of that is the large amount of backlog to be transferred at<br>>the start of the console session, which is typically when you need the<br>>current data the most. In most cases, this could just be stale data from<br>>a previous boot. Because of this, I think it'll be a net *loss* in<br>>usability.<br><div><br></div></div><div dir="ltr"><div>I was looking at how AMI and supermicro's console works in the UI, and when the console session is started</div><div>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? </div><div>I may be misunderstanding what is possible here.</div><div><br></div><div>I am also wondering if an implementation like this:</div><div> a) is adequate</div><div> 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)</div><div><br></div><div>Becca</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 6:37 AM Alexander Amelkin <<a href="mailto:a.amelkin@yadro.com" target="_blank">a.amelkin@yadro.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
<div class="m_7927845120496673542m_5796614707251720308moz-cite-prefix">25.08.2018 00:02, Tanous, Ed wrote:<br>
</div>
<blockquote type="cite">
<div class="m_7927845120496673542m_5796614707251720308WordSection1">
<p class="MsoNormal">I would like to start a discussion around
the feature of SOL logging, and how to best implement it.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">There is a proposal here <a href="https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-webui/+/12063/" target="_blank">
https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-webui/+/12063/</a>
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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u><br>
</p>
</div>
</blockquote>
That's exactly what we have implemented in our BMC for YADRO VESNIN.<br>
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).<br>
<br>
Alexander.<br>
</div>
</blockquote></div>
</blockquote></div>