Increase log verbosity of development app, add log-level config for production#128
Merged
dwilding merged 10 commits intocanonical:mainfrom Mar 4, 2026
Merged
Increase log verbosity of development app, add log-level config for production#128dwilding merged 10 commits intocanonical:mainfrom
dwilding merged 10 commits intocanonical:mainfrom
Conversation
weiiwang01
approved these changes
Mar 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR makes several logging-related improvements:
Defines a handler for the "root" logger, which lets us log from the app code. I've added a logging call to
achieved_level()indashboard/projects/models.pyto demonstrate the capability, and to support troubleshooting I'm doing elsewhere. Sample output:For the development app (run using
runserver), increased the log verbosity to DEBUG. I've excluded SQL queries and file reloads, otherwise the logs get very noisy, but have included comments about how to output those logs too. Seedashboard/dashboard/settings.py.Setting DEBUG level enabled me to catch the error fixed by #126.
For the production charm, made the log level configurable at the Juju level. The new config option
log-levelcontrols the Django app logs. For example:juju config dashboard log-level=debug. The default level isinfo.If an invalid log level is configured, the charm goes into blocked status with the message "Webserver configuration check failed, please review your charm configuration or database relation", which is defined by the PaaS charm. Running
juju debug-logshows a more specific message:log-leveldoesn't control the gunicorn logs (the web request logs). I think that's OK, as the main purpose oflog-levelis to make it easier to troubleshoot internal app issues - especially in our testing deployment.Unrelated changes: I ran
ruff formaton the Python code that I touched, for more consistent formatting.Manual checks
rockcraft.yaml? Remember to use the same version number inREADME.md. @dwilding TODO before merging