add Logger.Write method to interface

[abe-winter]

What changed

• add Write(*LogEntry) to the logger interface

Why

We need a public method that takes a pre-existing LogEntry to do subprocess re-logging in agent. (i.e. to consume, parse, and re-upload log lines without double-prefixing)

[dgottlieb]

I think I'm being looped in a bit late here. Does this have to do with the pattern matching log stuff the agent does?

What functionality is this offering? I would expect user-code that needed access to the structure log object could get that by implementing an appender.

[abe-winter]

my understanding is that the current public Logger interface will always format the input (i.e. add a date + level prefix on the front)

problem we are solving: in agent, we are capturing logs from subprocesses, parsing them, and then re-logging them. in theory this is necessary to use netappender without having a 'double prefix' issue

in the current agent PR, there's a global netappender which can receive a LogEntry; this works in theory, but in the spot where I consume the global netappender, I also have access to the logger which contains that netappender. james pointed out that if I could Write(LogEntry) on the logger, we are free + easy

[Otterverse]

I think I'm being looped in a bit late here. Does this have to do with the pattern matching log stuff the agent does?

What functionality is this offering? I would expect user-code that needed access to the structure log object could get that by implementing an appender.

To clarify, we have structured input already coming in. We want to write it directly, rather than generating new log entries (with potentially different data, like timestamps and filename:lineno combinations.) We want that to be written to the normal logger with the net appender.

In normal "zap" land, this would be done with something like logger.Core().Write(), but as this logging system in RDK was implemented as a wrapper on top of the zap logger, instead of something like a customized zap.Core, so doing that bypasses the appender functionality. This seems to be the next best solution instead, since we're not following the zap paradigm.

[Otterverse]

LGTM, but should wait until Dan is comfortable too.

[dgottlieb]

Ok, this makes sense to me now. Sorry I was being dense.

[dgottlieb]

No idea why the linter doesn't complain about any of these. Can we explicitly document this with:

Unconditionally logs a LogEntry object. Specifically any configured log level is ignored.

I might follow up with adding a Log(*LogEntry) that conditionally logs. So we can replace this switch statement usage.