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

Base logging todo #25109

Closed
10 of 15 tasks
c42f opened this issue Dec 15, 2017 · 8 comments
Closed
10 of 15 tasks

Base logging todo #25109

c42f opened this issue Dec 15, 2017 · 8 comments
Assignees
Labels
logging The logging framework

Comments

@c42f
Copy link
Member

c42f commented Dec 15, 2017

Now that #24490 is merged containing the core functionality, there's still a lot of loose ends to tidy up, but at least they can be merged incrementally. Here's a list [edit - organized and sorted by priority]:

Important user-visible changes for 1.0

Core log message generation

User experience / logger backends

Non-API breaking tweaks and bug fixes

Non critical breaking changes

  • Make @show use the logging system so that shown variables can be captured as values rather than text when desired. (Main issue - which log level should this be? debug kinda makes sense, but info is arguably more useful for quick hacking.) Didn't have time to do this before 1.0.
  • Improve @test_logs usage for matching multiple log messages - nicer syntax + be slightly more conservative about features.
  • Clean up @test_logs failure Test.Result type - improve the way test sets capture results.

Wildcards - advice needed

  • Log forwarding from remote workers. In particular people using parallel workloads probably care about this. Pkg2 also uses separate processes extensively, and the tests clearly ended up a bit of a mess, with some logs being captured on stderr from a separate process.
@StefanKarpinski
Copy link
Member

How much of this is user-visible? We should heavily prioritize user-visible changes since we're trying to do a feature freeze here and get an alpha out. Non-user-visible changes can continue to be made during the alpha period, although ideally those should be minimal, this seems important enough that we can allow it.

@c42f
Copy link
Member Author

c42f commented Dec 16, 2017

I've organized the list here into a rough priority. I think I've got a fairly solid handle on how to do most of these things because I've already done the bulk of the investigation work and a fair chunk of the code. As to priority, I've laid them out as I see them, roughly, but happy to rearrange a bit.

The main thing I feel quite unsure about at this point is the remote workers issue as I really haven't done any investigation here.

@StefanKarpinski
Copy link
Member

Remove --depwarn=error and replace with something finer grained.

Note that we can always keep this and add a more fine-grained mechanism on top of it in the future and just redefine the behavior of this option in terms of the more fine-grained mechanism.

@c42f
Copy link
Member Author

c42f commented Dec 16, 2017

That's a good point, it's not strictly required that this be deprecated. My concern is that when implementing this with a logger, --depwarn=error is essentially a logger configuration mechanism and I suspect a command line option will compose badly with whatever logging configuration system we end up with. It can probably be hacked together in some way.

@StefanKarpinski
Copy link
Member

I guess we can always deprecate --depwarn and codename the release "Inception".

@fredrikekre fredrikekre added the logging The logging framework label Dec 29, 2017
@c42f c42f self-assigned this Dec 30, 2017
@c42f c42f added logging The logging framework and removed logging The logging framework labels Dec 30, 2017
@samoconnor
Copy link
Contributor

@c42f Does the new logging infrastructure have support for multiple simultaneous log streams?
e.g. could I have a seperate log stream per task? or collect all the logs from a function call into a seperate log stream?

@c42f
Copy link
Member Author

c42f commented Feb 6, 2018

Yes, this is exactly the way it's designed: with_logger(f, logger) calls f with all logs for the current task directed to logger. In addition, any child tasks which are spawned by f (or any deeper part of the call stack) inherit logger as the task local logger.

@c42f
Copy link
Member Author

c42f commented Jun 12, 2020

This list is kinda out of date at this point. The items which haven't been dealt with are either low priority or are tracked in their own separate issues. So I think I'll close this.

@c42f c42f closed this as completed Jun 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
logging The logging framework
Projects
None yet
Development

No branches or pull requests

4 participants