Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow caller to control driver logging #149

Open
astrieanna opened this issue Oct 18, 2019 · 1 comment
Open

Allow caller to control driver logging #149

astrieanna opened this issue Oct 18, 2019 · 1 comment

Comments

@astrieanna
Copy link
Contributor

CLIs that use cnab-go should be able to:

  1. Control whether any output is written
  2. Control whether output is written to stdout or stderr
  3. Capture all output (i.e. to store logs for future reference)
  4. Get logs from all the code in the driver (i.e. SetConfig should be able to write logs, too)
  5. Separate logs from the invocation image from logs from the driver (very important for UX)
  6. Control verbosity of the driver logging

This is related to:

Currently, the caller can set stdout and stderr streams in the Operation, which allows the caller to control whether output is written, whether it's written to stdout/stderr, and to capture the output. It does not allow logging from SetConfig. There are not enough tests to ensure that the logging is consistently done only to the Operation streams.

Some possible approaches:

  • Use the same logging library in both the caller and cnab-go; for libraries with shared global settings, this would allow the caller to control the verbosity and make the logging more reliable (using a logging library is more obvious than digging up a stream from an object to write to), but doesn't distinguish container vs driver logs or necessarily allow the caller to capture all output.
  • Construct each driver with a logging object (streams or whatever); this could be similar to how logging works for the main function today, but the object with the streams needs to be introduced earlier, so that SetConfg can use it too. Because this would be a custom-for-drivers object, we could include separate streams for before the container runs, the output of the container, and after the container runs (to support the most basic form of interleaving logs when showing them to the user).

cc @youreddy @silvin-lubecki

@carolynvs
Copy link
Contributor

I recently fixed the docker driver in #234. It would be great to be able to separate out driver logs and the output of the bundle as well though. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants