SOL Logging

[Rebecca Broekhuis]

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.

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.

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.

-- Becca

On Mon, Aug 27, 2018 at 7:49 AM Andrew Geissler <geissonator at gmail.com>
wrote:

> On Fri, Aug 24, 2018 at 4:03 PM Tanous, Ed <ed.tanous at intel.com> 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.
>
> We use https://github.com/openbmc/obmc-console for this currently.  It
> creates a file at /var/log/obmc-console.log and even has a
> customizable size for the file to wrap at. I guess the advantage of
> having it in the GUI is the user could ensure a full dump of the
> console (vs. just grabbing the existing obmc-console.log which may
> have wrapped). Being able to view the SOL output has it happens in the
> GUI, then having an option to export it sounds kind of useful.  Also
> be nice to be able to retrieve and view the existing obmc-console.log
> from the system in case you missed it in the GUI.  Maybe that latter
> part is enough though, reduces GUI complexity and testing. Something
> good to run by our usability/design team Gunnar/Rebecca?
>
> >
> >
> > 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?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > -Ed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180827/1f8c5565/attachment.html>