SOL Logging

[Jeremy Kerr]

Hi Rebecca,

> You mentioned the possibility of pre-populating the scrollback buffer of 
> the console interface. I am wondering if you have any more information about
> how difficult this would be to implement.

It's easy to do, but difficult to do *correctly*.

A trivial implementation would just:
  1) serve the backlog at a specific static URL
  2) when the client established the live console connection, prepend
     the data from (1) into the session

However, getting the synchronisation between those two (as independent
channels of data) is difficult, and getting that wrong means either
missing or duplicated console data. We'd also need to handle the case
where the backlog has been rotated during the connection.

The logical fix for that would be to combine both channels into the one
stream (and further up the stack): when any client session connects to
the obmc-console server, the server replays the backlog before
outputting live data from the host. Because it's implemented
console-server-side, it would affect both web UI endpoint and the ssh
console endpoint.

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.

The alternative is just to make the backlog available as a separate
view, and not try to prepopulate the live console.

The console infrastructure really needs to be simple and correct; we use
it in low-level debugging, and complications in those situations can
cause major headaches. Because of this, I've tried to do no alteration
of the console data, keep the things simple, and treat the console
channel as opaque between host and client terminal.

Cheers,


Jeremy