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

Improve ducktape log collection spec #156

Open
ewencp opened this issue Jan 18, 2017 · 0 comments
Open

Improve ducktape log collection spec #156

ewencp opened this issue Jan 18, 2017 · 0 comments

Comments

@ewencp
Copy link
Contributor

ewencp commented Jan 18, 2017

Currently we collect logs based on a default specified in the Service class or if the test explicitly requests it (via mark_collect either for a single log file or defaulting to all of them). In practice, this has meant that logs are either always collected or not because it's not convenient to make assertions that throw exceptions if you have to also catch that exception and mark logs for collection.

Instead, a developer should be able to specify a different set of options for log collection such that it is fully automated by the ducktape framework and our existing Service classes should be upgraded to use this new approach. In particular the set of options that would probably make sense are:

  • Always – always collect the log file. Useful for basic INFO level logs from pretty much any service and test
  • On failure – the log is possibly large and only useful if the test fails. Example: verifiable producer/consumer generate a lot of output, but on success that output isn't useful. On error, it's basically required to debug the issue.
  • If explicitly requested – the mode currently required if you only sometimes want to collect them. Probably rarely used, but potentially useful if you only want to collect certain logs if specific failures occur (i.e. a particular validation fails)

If there's a good way to express alternatives, we may also want to support that. For example, we may have some services generate the same logs at two levels (e.g. INFO and DEBUG), and on failure you'll want the full DEBUG, but otherwise the INFO would be sufficient.

benthomasson added a commit to benthomasson/ducktape that referenced this issue Feb 8, 2017
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

1 participant