<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>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">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_5796614707251720308moz-cite-prefix">25.08.2018 00:02, Tanous, Ed wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      
      <div class="m_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>