-
Notifications
You must be signed in to change notification settings - Fork 275
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
Silence errors to be raised #1145
Silence errors to be raised #1145
Conversation
A mismatched length will lead to DownloadLengthMismatchError that will be handled by user. There is no need to log Errors or Criticals on the way. Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Looks good to me. |
Don't use log level ERROR when we are only raising an exception for user to handle (the issue is not a bug in TUF: TUF is working as expected in all of these cases). Don't log at all if all the info is included in the raised exception. Also definitely don't log at error level when we don't know if this will even be raised (e.g. a 404 is expected at least once on every Updater.refresh()). Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
All of these tests create an exception and log it. They do not actually test anything. The alternative would be to change the log level to something that is not error to prevent verbose error output on successful test runs -- but that still wouldn't make them actual tests. Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
99a597e
to
0dd7ef8
Compare
all test_*.py files now accept zero or more '-v' to increase tuf logging level. The default is now ERROR. default: ERROR "-v": ERROR, but unittest prints test names "-vv": WARNING "-vvv": INFO "-vvvv": DEBUG Example to run a single test with DEBUG level: python3 test_updater.py -vvvv TestUpdater.test_4_refresh Also make test_log.py restore the log level it modifies during test. Fixes theupdateframework#1093 Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
0dd7ef8
to
03b15fb
Compare
Fixes theupdateframework#1076. Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
We want the tests own log output visible as well, and they are not under the "tuf" logger. Set root level to the same value as "tuf". Signed-off-by: Jussi Kukkonen <jkukkonen@vmware.com>
Something that may not be obvious: Running some tests like test_updater.py (at default ERROR level) is currently still very chatty because we get a lot of warnings. Warnings are not integrated into the logging system by default, but we should be able to make them into e.g. WARNING level log entries quite easily: then the default output would be quite nice. However, ideally we should fix the warnings instead of hiding them so I've not done the integration here (EDIT: this was annoying enough that I finished my ResourceWarning cleanup: #1147). |
parser.add_argument('-v', '--verbose', action='count', default=0) | ||
args, _ = parser.parse_known_args(argv) | ||
|
||
if args.verbose <= 1: |
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.
In your commit message, you have mentioned that the number of v
means the following:
default: ERROR
"-v": ERROR, but unittest prints test names
"-vv": WARNING
"-vvv": INFO
"-vvvv": DEBUG
I think this should be documented somewhere.
Can we have like --help
argument and functionality?
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 wish we could... but I don't see a way to do that without breaking unittest --help. The lack of discoverability is annoying but I just don't know how to make it better (without essentially hiding unittest functionality, which I also don't want to do)
Looks good to me besides my comment. I am glad you have removed |
I half-expected this to change the coverage, but it's still at 97% 🤷♂️
I think this one is worth an issue, would you mind creating one? |
#1148 is about |
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.
Great set of cleanups for logging, thanks @jku. I have a question in-line about how you're choosing logging levels, I think I figured it out in most cases apart from that one.
@@ -278,7 +278,7 @@ def _download_file(url, required_length, STRICT_REQUIRED_LENGTH=True): | |||
except Exception: | |||
# Close 'temp_file'. Any written data is lost. | |||
temp_file.close() | |||
logger.exception('Could not download URL: ' + repr(url)) | |||
logger.debug('Could not download URL: ' + repr(url)) |
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.
Can you elaborate on why you chose debug level here?
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 don't have a strong opinion here, but I think the reason I went with debug() was to avoid info() for things that
- do happen in normal usage
- are then raised as exceptions and handled in calling code: in this case Updater will usually log 'Update failed from ...' also at debug level
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.
just so I'm not misleading: 'Update failed from ...' log level was also chosen by me in this PR.
The point that I tried to make was that the 'lower level code' (download) probably should not log at INFO if the 'higher level code' (Updater) logs the same thing at DEBUG. A case could be made for the Updater logs for failed updates to be INFO though...
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.
And that logging in updater is only a DEBUG because an exception is raised if all mirrors fail. This makes sense, thanks for providing that extra context.
I agree, a case could be made for info. But I'm not making that case here.
Fixes #1108, fixes #1093
This does not fix every logging inconsistency but it does fix issues that become visible in normal usage when running the updater at log level ERROR.
I decided to not try issue #1120 in the same PR (as it might require more discussion), but did fix #1093 (Option to show log output when running individual tests) because that is needed to easily verify these fixes. Now you can run e.g.
to run a specific test with DEBUG level output. The default level is ERROR.
Description of the changes being introduced by the pull request:
I still have these complaints/questions (but personally can live with the PR as is):
Please verify and check that the pull request fulfills the following
requirements: