Charm doesn't react to pebble_ready so if the workload container restarts the charm stays in maintenance status

[mthaddon]

Describe the bug

The charm doesn't react to pebble_ready so if the workload container restarts the charm stays in maintenance status.

To Reproduce

1. Deploy the charm
2. Restart the workload (lego) container
3. Observe the status in juju remains as "maintenance"

Expected behavior

The charm should be active/idle.

Screenshots

N/A

Logs

N/A

Environment

• Charm / library version (if relevant): 40
• Juju version (output from juju --version): 3.1.8
• Cloud Environment: OpenStack
• Kubernetes version (output from kubectl version --short): Client Version: v1.29.4
  Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
  Server Version: v1.26.15

Additional context

N/A

[gruyaume]

Thank you for opening this issue @mthaddon, we added this to our next pulse.

[gruyaume]

I'm pretty sure this was fixed when we moved to using collect_status instead of observing individual events to set the charm status.

I'll promote the charm from edge to candidate. @mthaddon can you validate if you are still experiencing the issue with the candidate release?

juju deploy httprequest-lego-k8s --channel=candidate

[mthaddon]

I can't see a way to manually kill the workload container for this charm, as there's no shell for me to connect to the workload container, and pebble plan seems to be empty (I've just deployed the charm and set httpreq_endpoint and email but not related it to anything). Do you have any ideas of how to manually kill the lego container so that I can test this?

[gruyaume]

Indeed, there is no pebble plan, we are only using LEGO cli calls when needed. Here I simply deleted the k8s pod.

kubectl delete pod <pod name> -n <model name>

[mthaddon]

@gruyaume that deletes the entire pod. What I need to do here to confirm if the bug is fixed is to kill the lego container (which will then be restarted) but leave the charm container running.

[mthaddon]

Just for a bit more context, here's the output of kubectl describe pod and the previous container logs for the lego container on an instance manifesting this bug: https://pastebin.ubuntu.com/p/nZdqgtKkwt/

As you can see, the lego container has been restarted twice, and the last restart was on Wed, 17 Apr 2024 19:11:04 +0000.

[gruyaume]

I'm quite confident this would have been fixed by switching to "collect status" as status will be evaluated at every event now. I'm not quite sure how to confirm this 100%.