make loglevel usage sane
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cloud-init |
Expired
|
Undecided
|
Unassigned | ||
Bug Description
Seen with cloud-init-
This is debug:
2018-10-31 13:57:37,557 - util.py[DEBUG]: Reading from /etc/cloud/
2018-10-31 13:57:37,557 - util.py[DEBUG]: Read 2178 bytes from /etc/cloud/
2018-10-31 13:57:37,557 - util.py[DEBUG]: Attempting to load yaml from string of length 2178 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,564 - util.py[DEBUG]: Reading from /etc/cloud/
2018-10-31 13:57:37,565 - util.py[DEBUG]: Read 2057 bytes from /etc/cloud/
2018-10-31 13:57:37,565 - util.py[DEBUG]: Attempting to load yaml from string of length 2057 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,570 - util.py[DEBUG]: Reading from /run/cloud-
2018-10-31 13:57:37,570 - util.py[DEBUG]: Read 35 bytes from /run/cloud-
2018-10-31 13:57:37,570 - util.py[DEBUG]: Attempting to load yaml from string of length 35 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,571 - util.py[DEBUG]: Attempting to load yaml from string of length 0 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,571 - util.py[DEBUG]: loaded blob returned None, returning default.
2018-10-31 13:57:37,571 - util.py[DEBUG]: Reading from /var/lib/
2018-10-31 13:57:37,572 - util.py[DEBUG]: Read 1682 bytes from /var/lib/
2018-10-31 13:57:37,572 - util.py[DEBUG]: Attempting to load yaml from string of length 1682 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,577 - util.py[DEBUG]: Reading from /var/lib/
2018-10-31 13:57:37,577 - util.py[DEBUG]: Read 1682 bytes from /var/lib/
2018-10-31 13:57:37,577 - util.py[DEBUG]: Attempting to load yaml from string of length 1682 with allowed root types (<class 'dict'>,)
2018-10-31 13:57:37,584 - util.py[DEBUG]: Writing to /var/lib/
2018-10-31 13:57:37,586 - main.py[DEBUG]: no di_report found in config.
This is important:
2018-10-31 13:57:37,530 - stages.py[DEBUG]: not a new instance. network config is not applied.
Both are marked a debug. So currently I default to use "grep -v util.py" when looking at cloud init logs to retain my own sanity. I think it is possible to make it easier than this for admins to use cloud-init. Especially as when compared to 0.7.9 cloud-init has seem to become way more complex and more difficult to understand.
| Chad Smith (chad.smith) wrote | #1 |
| Changed in cloud-init: | |
| status: | New → Incomplete |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in cloud-init: | |
| status: | Incomplete → Expired |
| James Falcon (falcojr) wrote | #3 |
Thank you for filing this bug and making cloud-init better. In this specific logged case, that log message was only indicating that no config-related action was taken on the machine, so it does feel properly leveled at DEBUG because this is intended behavior in cloud-init across reboots when no instance data changes to indicate cloud-init should re-run various configuration modules. It feels a bit like reverse grep ruling out log messages based on a specific module util.py will only mask potential errors or warnings that are emitted from that module and still leave noisy debug messages from all other modules.
May I suggest instead to look only at info, warning and error level messages?
cloud-init tries to use INFO WARNING and ERROR log level to indicate something the user should pay attention to, so a more appropriate grep would be egrep 'INFO|WARNING|
For example, if cloud-init is performing a network configuration change we'd see the following INFO level message
2019-01-18 21:25:25,933 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 1, 'config': [{'subnets': [{'type': 'dhcp', 'control': 'auto'}], 'type': 'physical', 'name': 'eth0'}]}
Alternatively: cloud-init status --long on newer cloud-init v 18.x will report specific errors from the cli so you don't have to dive into the noisy log in the first place.