)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":34975,"name":"Jaromír Wysoglad","email":"jwysogla@redhat.com","username":"jwysogla"},"change_message_id":"52f3ecf010eac94c8aa47d40dfd18f0c1b475d4a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"dd08f7ad_e38a9cd8","updated":"2026-06-09 09:23:52.000000000","message":"What is this trying to achieve? As far as I see, the log.register_options (L67 in this file) registers the `default_log_levels` config option with the same defaults as the `get_default_log_levels()` returns (they both use this https://opendev.org/openstack/oslo.log/src/commit/692ec8617a5d23dc36c592e31367e46e04c7ce8f/oslo_log/_options.py#L19). But while the current code registers the option and lets users change it in aodh.conf to influence the log levels, with this change the option would be registered, but as far as I see it wouldn\u0027t actually be used anywhere, so users would lose the ability to set the log levels.\n\nTo put it short, I think the default would stay the same, but we\u0027d lose customizebility.","commit_id":"6a3eb0d919a6c5868080b711f082296b47dbe015"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"864cecb7e175d431ad02aeb76c558636d1c9b152","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bef379ab_61ee3d50","updated":"2026-06-02 13:54:54.000000000","message":"recheck","commit_id":"6a3eb0d919a6c5868080b711f082296b47dbe015"},{"author":{"_account_id":34975,"name":"Jaromír Wysoglad","email":"jwysogla@redhat.com","username":"jwysogla"},"change_message_id":"62891f451a9b5854da44e8546556387fd3bc8975","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"751cdf95_55b9f1a2","in_reply_to":"bac1f0c2_37c8c9fe","updated":"2026-06-10 06:41:07.000000000","message":"I see. We have log.setup call on L96, which from a quick read of oslo_log reads the config and it\u0027ll use whatever is configured in the default_log_levels in the config, so that\u0027s where the customizebility is kept. In that case this is fine. Thank you!","commit_id":"6a3eb0d919a6c5868080b711f082296b47dbe015"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"8e6816a8118caf5373ac04d3b63b6a3b13b6736d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bac1f0c2_37c8c9fe","in_reply_to":"dd08f7ad_e38a9cd8","updated":"2026-06-09 15:07:16.000000000","message":"No, customizebility is not lost. The change affects only the way to pick up the default value of the default_log_level.\n\nThe aim of this change is to get rid of the discouraged use of uninitialized config value. Ideally we should not access anything under conf until https://review.opendev.org/c/openstack/aodh/+/990933/1/aodh/service.py#91 is called and then all options are properly loaded from config files. This behavior is currently not guaranteed and sometimes such read-before-load caused failure from oslo.log. The oslo.config interface https://review.opendev.org/c/openstack/oslo.log/+/263468 was introduced to load hard-coded value defined in oslo.config instead of directly reading the ConfigOpt instance which may not be initialized yet.","commit_id":"6a3eb0d919a6c5868080b711f082296b47dbe015"}]}