Although I couldn't prove yet, this should fix #24 because this PR introduces updatetz to be an additional init container and the init container ensures that the Time Zone database is updated at least once before cronjobber starts.
I've updated the version to 0.1.1 but the docker image is not built (I presume the owner will build it).
Below is the outcome of the test I performed for this PR (some details are masked):
describe pod after deployment
fethi.ozdol$ kubectl describe pod cronjobber-yyyyyyyyyyyy -c init-updatetz
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Pulling 16s kubelet, xxxxxxxxx Pulling image "xxxxxxxxx/cronjobber-updatetz:0.1.1"
Normal Pulled 15s kubelet, xxxxxxxxx Successfully pulled image "xxxxxxxxx/cronjobber-updatetz:0.1.1"
Normal Created 15s kubelet, xxxxxxxxx Created container init-updatetz
Normal Started 14s kubelet, xxxxxxxxx Started container init-updatetz
Normal Pulled 6s kubelet, xxxxxxxxx Container image "quay.io/hiddeco/cronjobber:0.2.0" already present on machine
Normal Created 6s kubelet, xxxxxxxxx Created container cronjobber
Normal Started 5s kubelet, xxxxxxxxx Started container cronjobber
Normal Pulling 5s kubelet, xxxxxxxxx Pulling image "xxxxxxxxx/cronjobber-updatetz:0.1.1"
Normal Pulled 5s kubelet, xxxxxxxxx Successfully pulled image "xxxxxxxxx/cronjobber-updatetz:0.1.1"
Normal Created 5s kubelet, xxxxxxxxx Created container updatetz
Normal Started 5s kubelet, xxxxxxxxx Started container updatetz
cronjobber logs
fethi.ozdol$ kubectl logs cronjobber-yyyyyyyyyyyy -c init-updatetz
2020-05-19T18:38:07+0000 Local Time Zone database updated to version 2020a on /tmp/zoneinfo
fethi.ozdol$ kubectl logs cronjobber-yyyyyyyyyyyy -c updatetz
2020-05-19T18:38:11+0000 Local Time Zone database is up to date
fethi.ozdol$ kubectl logs cronjobber-yyyyyyyyyyyy -c cronjobber
W0519 18:38:09.147422 1 client_config.go:548] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
{"level":"info","ts":"2020-05-19T18:38:09.158Z","caller":"cronjobber/main.go:64","msg":"Connected to Kubernetes API: v1.14.9-zzzzzzzz"}
{"level":"info","ts":"2020-05-19T18:38:09.158Z","caller":"cronjobber/main.go:75","msg":"Starting Cronjobber version 0.2.0 revision f860bc912c395c58fa72741d8d34e8bf4b1a2c00"}
{"level":"info","ts":"2020-05-19T18:38:09.158Z","caller":"cronjobber/controller.go:106","msg":"Starting TZCronJob Manager"}
Note that;
1- init-updatetz updates the local time zone database at 18:38:07
2- updatetz says the local time zone database is already up to date at 18:38:11.
3- cronjobber starts at 18:38:09, which is post init-updatetz
Although I couldn't prove yet, this should fix #24 because this PR introduces updatetz to be an additional init container and the init container ensures that the Time Zone database is updated at least once before cronjobber starts.
I've updated the version to 0.1.1 but the docker image is not built (I presume the owner will build it).
Below is the outcome of the test I performed for this PR (some details are masked):
describe pod after deployment
cronjobber logs
Note that; 1- init-updatetz updates the local time zone database at 18:38:07 2- updatetz says the local time zone database is already up to date at 18:38:11. 3- cronjobber starts at 18:38:09, which is post init-updatetz