Workload doesn't restart after charm's reconfiguration. This means that if the workload is misconfigured, it will restart once it hits the health check's threshold (around 3 and half minutes after deployment (threshold * (period + timeout)). But the workload "unhealthiness" will be visible to the user once an update-status is fired, which is 5 minutes after deployment. If then, a user reconfigures the workload, that won't have an effect to the actual workload, since the workload won't be restarted. Instead, it will keep its initial configuration and the workload will log health check failures trying to hit the previous port.
The opposite scenario also exposes the same issue: if its port configuration is modified after deploying the charm, this doesn't affect the charm and the charm remains healthy (considering that the charms is reconfigured in an inappropriate way). This shows that its workload isn't restarted and still uses the initial port provided.
Update-status
During udpate status, the charm's status will be set to Maintenance (Workload failed health check) and it will log the following which is inaccurate since the workload won't be restarted every time an update-status is received rather only when threshold is hit.
unit-admission-webhook-0: 14:54:48 ERROR unit.admission-webhook/0.juju-log Container admission-webhook failed health check. It will be restarted.
Questions
Is pebble expected to restart the workload only once, when the health check failures' threshold is hit and not ever again? Asked about this in a matrix thread
Should config-changed events restart the workload? I understand that yes since charm updates its layer. For comparison, observing oidc-gatekeeper behaviour, once its public-url is reconfigured, the workload is actually restarted. I 'm not how this may interact with its service_patch which is configured during init().
What should we log?
To Reproduce
Deploy admission-webhook charm with its port misconfigured e.g. with argument --config port=3333
Bug Description
Workload doesn't restart after charm's reconfiguration. This means that if the workload is misconfigured, it will restart once it hits the health check's threshold (around 3 and half minutes after deployment (threshold * (period + timeout)). But the workload "unhealthiness" will be visible to the user once an
update-status
is fired, which is 5 minutes after deployment. If then, a user reconfigures the workload, that won't have an effect to the actual workload, since the workload won't be restarted. Instead, it will keep its initial configuration and the workload will log health check failures trying to hit the previous port.The opposite scenario also exposes the same issue: if its port configuration is modified after deploying the charm, this doesn't affect the charm and the charm remains healthy (considering that the charms is reconfigured in an inappropriate way). This shows that its workload isn't restarted and still uses the initial port provided.
Update-status
During udpate status, the charm's status will be set to
Maintenance (Workload failed health check)
and it will log the following which is inaccurate since the workload won't be restarted every time anupdate-status
is received rather only when threshold is hit.Questions
config-changed
events restart the workload? I understand that yes since charm updates its layer. For comparison, observing oidc-gatekeeper behaviour, once itspublic-url
is reconfigured, the workload is actually restarted. I 'm not how this may interact with its service_patch which is configured duringinit()
.To Reproduce
--config port=3333
Environment
╰─$ microk8s version
MicroK8s v1.26.11 revision 6237
╰─$ juju version --all version: 3.1.7-genericlinux-amd64 git-commit: 0cd207d999fef1fc8b965c410e9f58fafe7ee335 git-tree-state: archive
Relevant Log Output
Additional Context
No response