Right now libcnb has the poet module for logging. It will write logging information, much of it is at the debug level (there are some things like warning messages that get written at the info level), and this information uses the format and output defined in libcnb.
If you are wrapping libcnb, like with libpak or like we'd like to do with packit then you end up with logging that is disjoint. Indentations don't line up nicely, colors may be off, etc...
This issue is to discuss how we can structure libcnbv2 such that logging output can be controlled in a more uniform manner.
A couple of options have been discussed in the BAT meeting, here are some notes:
Expose a logging facade from libcnb. Libcnb writes logs using the logging facade. Libcnb would provide a basic implementation of the facade for use in cases where only libcnb is used. In the case of extending libcnb, the extending library could provide its own implementation of the facade. The implementation would dictate formatting, indentation, color, etc.. The control over how things look would be made consistent across all buildpacks using that implementation.
This has a couple of drawbacks. We'd have to expose our own facade, which is yet another logging API. It would also not solve the case where you have a composite buildpack made up of buildpacks that use different implementations, you could still have disjoint output there.
There was also some discussion about using Open Telemetry for logging. This has the advantage that there's already an API to use in buildpacks. Everyone would essentially use this API, logs would be written out in a structured format. Then based on some yet to be determined configuration, possibly set through the builder or a composite buildpack, the structured format could optionally be translated by the platform into a more human-friendly format. The format could control things like indentation, colors, etc...
The main complication here is that this requires changes and adoption by the platforms. We'd also have to consider backward compatibility. If running on an older platform, what happens to the output?
dmikusa
commented
2 years ago
Right now libcnb has the poet module for logging. It will write logging information, much of it is at the debug level (there are some things like warning messages that get written at the info level), and this information uses the format and output defined in libcnb.
If you are wrapping libcnb, like with libpak or like we'd like to do with packit then you end up with logging that is disjoint. Indentations don't line up nicely, colors may be off, etc...
This issue is to discuss how we can structure libcnbv2 such that logging output can be controlled in a more uniform manner.
A couple of options have been discussed in the BAT meeting, here are some notes:
Expose a logging facade from libcnb. Libcnb writes logs using the logging facade. Libcnb would provide a basic implementation of the facade for use in cases where only libcnb is used. In the case of extending libcnb, the extending library could provide its own implementation of the facade. The implementation would dictate formatting, indentation, color, etc.. The control over how things look would be made consistent across all buildpacks using that implementation.
This has a couple of drawbacks. We'd have to expose our own facade, which is yet another logging API. It would also not solve the case where you have a composite buildpack made up of buildpacks that use different implementations, you could still have disjoint output there.
There was also some discussion about using Open Telemetry for logging. This has the advantage that there's already an API to use in buildpacks. Everyone would essentially use this API, logs would be written out in a structured format. Then based on some yet to be determined configuration, possibly set through the builder or a composite buildpack, the structured format could optionally be translated by the platform into a more human-friendly format. The format could control things like indentation, colors, etc...
The main complication here is that this requires changes and adoption by the platforms. We'd also have to consider backward compatibility. If running on an older platform, what happens to the output?