-
Notifications
You must be signed in to change notification settings - Fork 903
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
Alter framework logging.yml configuration #1491
Conversation
Signed-off-by: Ahdra Merali <[email protected]>
kedro/config/logging.yml
Outdated
@@ -33,15 +33,21 @@ handlers: | |||
|
|||
loggers: | |||
anyconfig: | |||
level: WARNING | |||
handlers: [console] | |||
level: INFO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why anyconfig
level is changed from WARNING
to INFO
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops - thanks for the catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit surprise the kedro.framework.session
related log seems missing after the changes?
As am I 🤔 ; converting to draft to address the e2e tests and investigate further |
Thanks for all very thorough testing and observations noted here. I've written a comment in #1461 to explain better how kedro logging works so that everyone can understand this better, because it is quite confusing. Given the above let me explain the differences that I see here (please do say if I missed any!):
All the above logs are emitted before the project-side logging.yml is loaded and hence just the framework-side logging.yml is used, which is why changing the framework-side logging.yml has changed them. When you removed our custom Now, which (if any) of these are problems and do we need to rethink what we're doing here? I think we're on the right lines and this is ok so far, but once I've had a chance to think a bit more about it later this morning I will say if that's not the case! |
Follow up on @AntonyMilneQB comments about the 3 changes.
|
Following some changes I've made here and #1506, I think the behaviour after this PR will not result in any observable differences compared to how things currently run. The only (very small) change is that messages of level <= INFO emitted by things outside kedro before project-side logging config is setup used to be logged and no longer will be. This is an improvement and means we can drop the So in reference to the 3 above messages:
|
Thanks, I think changing the hook specific logger to |
Now that #1506 has been merged I've tested this again and all behaves as expected:
Marking this as ready to review since I think it we're all good here now and it would be nice to get it merged in so we can make progress on the following tickets that depend on it 🙂 Looks like I need to fix up a couple of tests - working on that now... |
Signed-off-by: Antony Milne <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! The log now looks good to me. Good to be merged after fixing the tests.
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
Signed-off-by: Antony Milne <[email protected]>
…fig' into feat/alter-framework-logging-config Signed-off-by: Antony Milne <[email protected]> Signed-off-by: Antony Milne <[email protected]>
@@ -39,7 +39,7 @@ min-public-methods = 1 | |||
[tool.coverage.report] | |||
fail_under = 100 | |||
show_missing = true | |||
omit = ["kedro/templates/*", "kedro/framework/cli/hooks/specs.py", "kedro/framework/hooks/specs.py", "kedro/extras/datasets/tensorflow/*", "kedro/extras/datasets/holoviews/*", "tests/*"] | |||
omit = ["kedro/templates/*", "kedro/extras/logging/color_logger.py", "kedro/framework/cli/hooks/specs.py", "kedro/framework/hooks/specs.py", "kedro/extras/datasets/tensorflow/*", "kedro/extras/datasets/holoviews/*", "tests/*"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added the color logger here. I actually have no idea why we were getting 100% coverage before because this file has never been fully tested... But given that we're going to deprecate it I decided just to add it to the coverage ignore rather than write tests for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't there a test_color_logger.py
? It's probably not related but seen this from Kiyo yesterday. https://921kiyo.com/code-coverage-level-with-pytest-cov/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is, but it only tests how the color logger handles INFO
level messages. Ideally it would go through every level of logging and test them all. I don't know how it was passing coverage before given none of the other levels are tested 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting post on the different coverage levels, I didn't know about that before! I wonder what we'd get if we added --cov-branch
to our tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question to understand the changes better, but not blocking and I'm happy with merging this!
kedro: | ||
level: INFO | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally in #1470 we needed to add handlers
and propagate
to all loggers. Why is this no longer needed? And what exactly do these things do? I still find the logging behaviour a bit mysterious 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I only fully understood this after reading the logging docs for the 1000th time last week 😀 This will become clearer with examples when we complete #1474 and I'm happy to present to the team to explain further, but in brief:
- loggers work hierarchically and activate all loggers above them. e.g. when
kedro.x.y
does logging it will also log to any loggers namedkedro.x
andkedro
.root
is the at the top of the hierarchy - the above is the case when
propagate: true
(the default ifpropagate
is not specified explicitly). If you setpropagate: false
then a logging call tokedro.x.y
will not activate any other loggers - if you propagate to higher up loggers then if they both have the same handler, this handler will be called separately by each logger that uses it. This results in duplicated log messages
- our general strategy according to the Python docs should be to delegate as much as possible to the highest up logger (so
root
if possible), attach handlers to that logger and then allow lower level handlers just to propagate their calls up the chain
The docs on propagate
are quite clear and helpful for explaining all this more.
In practice, what happens now is that any logging done anywhere inside kedro will be propagated up to the root logger, which attaches the required handlers. i.e. if kedro.x.y
does a logging call then it will check if there's any logger defined explicitly for kedro.x.y
(there isn't), then it will check for kedro.x
(there isn't), then kedro
(which is defined). kedro
doesn't define any handlers, so it gets propagates up to root
, which is the thing that actually calls the handlers. The point in defining kedro
as a logger is just so we can set level: INFO
so that any info log messages coming from kedro are shown. The default level set by root
(and hence by all other logging calls outside kedro
) is WARNING.
kedro.framework.cli.hooks.manager
is a weird special case that will hopefully disappear in the near future if we remove the file handlers from the root logger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this explanation @AntonyMilneQB! It makes a lot more sense now 😄
Signed-off-by: Ahdra Merali [email protected]
Description
Adds the changes outlined in #1470 to update the inbuilt logging setup.
Development notes
The changes were tested by running some cli commands and noting the changes in the output between this and the unchanged version, and between valid and invalid pipelines. The only divergence in output was noted when running
kedro ipython
Original output
Updated output
Checklist
RELEASE.md
file