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

Refactor console output #22

Open
2 tasks
rainest opened this issue Nov 30, 2023 · 2 comments
Open
2 tasks

Refactor console output #22

rainest opened this issue Nov 30, 2023 · 2 comments

Comments

@rainest
Copy link
Collaborator

rainest commented Nov 30, 2023

The original deck design of these libraries had very limited logging. It did not use a logging library, and instead uses a basic wrapper around fmt.Println() to output directly to stdout/stderr. It has a basic global on/off toggle at the library level, though some consumers further add their own wrappers to simulate additional log levels.

To better make these packages a library, we should instead use a logging library or return rich structures to allow consumers to choose their desired log level and behavior. Library features that currently use cprint should instead accept a logger from their instantiator and send log lines to it an appropriate verbosity level, or should eschew logging altogether in favor of returning data that callers can handle as they wish.

There are currently 3 uses of cprint in this library:

  • The diff packages prints updated resource lines and possibly JSON diffs.
  • The types basic-auth handler has a warning it prints when you attempt to use basic-auths with deck.
  • The util package can print a warning called from file.Builder.build() if routes use regex syntax incompatible with their version.

The nature of these uses push me towards saying using returned values rather than accepting a logger. The full JSON diffs offered by diff do not readily work with most logging systems, since they're ideally printed over multiple lines for human consumption. These probably require handling (outside the normal logging system) downstream to present effectively. Continuing to print these to stderr makes sense for the deck CLI, but not so much for KIC--KIC does currently dump these to log output at higher verbosity, but it'd probably make more sense to place these in a separate file accessible via the config diagnostic API.

The warning print should probably be handled via initial scans of the input YAML. The deck CLI can scan input to see if basic-auths are present at all and print that warning (though weirdly as I read it we currently only print these on delete actions? idk why--this feature maybe needs further review), and can scan for regexes that don't match the Kong version similarly. KIC simply does not generate the wrong regex type, and has no issues using basic-auth that I know of.

Acceptance:

  • go-database-reconciler no longer provides the cprint package. Any downstream consumers (likely only deck) provide their own instead if its functionality is desired.
  • Functionality that currently uses cprint instead returns rich values that it would have previously formatted and output itself.
@Tieske
Copy link
Member

Tieske commented Dec 1, 2023

Looking at the landscape we have now;

  • database reconciler
  • go-apiops
  • kic (depending on database reconciler)
  • deck (depending on database reconciler, and go-apiops)

Prior art: shared-go (private repo https://github.com/Kong/shared-go)

There is now also a warning if reading from stdin.

So all uses:

  • The diff packages prints updated resource lines and possibly JSON diffs.
  • The types basic-auth handler has a warning it prints when you attempt to use basic-auths with deck.
  • The util package can print a warning called from file.Builder.build() if routes use regex syntax incompatible with their version.
  • file.readfile print warning when reading from stdin

The latter 3 are all stderr type output, only diff produces "user" output.

So my take would be to implement a standard logging mechanism. And only diff would use another for-purpose solution.

@czeslavo
Copy link

@rainest Should this be closed given #76 has been merged?

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

3 participants