<div dir="ltr">I agree with what you're saying about the javascript implementation of this being limited. Besides the session being destroyed upon leaving the page, I am also seeing that we are losing console messages in the front end when the websocket closes for a moment (which it is consistently doing during power on). We lose those messages sent during the time it takes to re-open the connection. They aren't displayed in the terminal emulator and therefore aren't exported to the text file when the user clicks 'export'. I could see that as another reason to implement the ability to download the existing obmc-console.log, since the pure javascript way of exporting to a text file could be an incomplete log in some cases.<div><br></div><div>There might be a another way to address missing messages as a result of the websocket closing, but from my current understanding it seems like another reason having the javascript export exclusively would be an unreliable option.<br><br>I can also see how having both downloads available could be confusing to the user -- I'd be happy to run this by the design team to see if they have input.</div><div><br></div><div>-- Becca</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 7:49 AM Andrew Geissler <<a href="mailto:geissonator@gmail.com">geissonator@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 24, 2018 at 4:03 PM Tanous, Ed <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<br>
><br>
> I would like to start a discussion around the feature of SOL logging, and how to best implement it.<br>
><br>
><br>
><br>
> There is a proposal here <a href="https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-webui/+/12063/" rel="noreferrer" 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.<br>
><br>
><br>
><br>
> 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.<br>
<br>
We use <a href="https://github.com/openbmc/obmc-console" rel="noreferrer" target="_blank">https://github.com/openbmc/obmc-console</a> for this currently.  It<br>
creates a file at /var/log/obmc-console.log and even has a<br>
customizable size for the file to wrap at. I guess the advantage of<br>
having it in the GUI is the user could ensure a full dump of the<br>
console (vs. just grabbing the existing obmc-console.log which may<br>
have wrapped). Being able to view the SOL output has it happens in the<br>
GUI, then having an option to export it sounds kind of useful.  Also<br>
be nice to be able to retrieve and view the existing obmc-console.log<br>
from the system in case you missed it in the GUI.  Maybe that latter<br>
part is enough though, reduces GUI complexity and testing. Something<br>
good to run by our usability/design team Gunnar/Rebecca?<br>
<br>
><br>
><br>
> 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?<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
><br>
> -Ed<br>
</blockquote></div>