latest/edge logrotated workload status stuck in maintenance when update-cron-daily-schedule is unset

[Konstantinos Kaskavelis]

SQA has a failed run,in a jammy baremetal run, at kubernetes-maas layer, where logrotated charm is stuck in maintenance with the message: Executing cron job.

From the logs' investigation, we could not identify the root cause for this, so we would appreciate any suggestion.

Failed run:

https://solutions.qa.canonical.com/v2/testruns/46b3f790-5d92-4b79-ace6-7e92b9eba920

Logs:

https://oil-jenkins.canonical.com/artifacts/46b3f790-5d92-4b79-ace6-7e92b9eba920/index.html

[Jeffrey Chang (modern911)]

Solutions QA has 18 failures in last 3 days, all of them are on jammy-baremetal with kubernetes 1.27.

[Alexander Balderson (asbalderson)]

I was able to catch this in a live environment and did some additional debugging.

The first note is that we only hit this bug running latest/edge, revision 12. The only configuration we set is `logrotate-retention: 60` and use defaults for everything else.

I dont have the live environment up any longer to get the _exact_ logs, but when i called the cronjob directly installed in /etc/logrotate_cronjob_config, and built on line 66 of lib_cron [1] the cronjob failed because it was trying to find a method in lib_cron called "None" [2]. When i looked at the cron_daily_schedule the values were to:
True
hourly
60
unset

This last value "unset" is the offending parameter, which is a new param for the edge/candidate version of the charm. This behavior may be expected overall, but could return a better message about being unset, instead of stuck "Executing cron job." when the hook is expected to fail. maybe return the message "cron schedule unset, please set to unblock charm."

1) https://git.launchpad.net/charm-logrotated/tree/src/lib/lib_cron.py#n66
2) https://git.launchpad.net/charm-logrotated/tree/src/lib/lib_cron.py#n157