Blocked Status disappears after unrelated charm action
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Kubernetes Control Plane Charm |
Fix Committed
|
High
|
Adam Dyess | ||
Kubernetes Worker Charm |
Fix Committed
|
High
|
Adam Dyess |
Bug Description
1.29, 1.30, and 1.31 charm can block for multiple reasons during the reconciler's loop, but only one status message can bubble out to the unit.
In the following pastebin https:/
```
unit-kubernetes
unit-kubernetes
...
unit-kubernetes
unit-kubernetes
unit-kubernetes
```
Running the upgrade action caused the ceph-client blocked message to be dropped.
The reconciler shouldn't drop blocked status messages like these
Changed in charm-kubernetes-worker: | |
milestone: | none → 1.31+ck1 |
Changed in charm-kubernetes-master: | |
milestone: | none → 1.31+ck1 |
status: | New → Confirmed |
Changed in charm-kubernetes-worker: | |
status: | New → Confirmed |
Changed in charm-kubernetes-master: | |
importance: | Undecided → Medium |
Changed in charm-kubernetes-worker: | |
importance: | Undecided → High |
Changed in charm-kubernetes-master: | |
importance: | Medium → High |
importance: | High → Medium |
Changed in charm-kubernetes-worker: | |
importance: | High → Medium |
tags: | added: backport-needed |
Changed in charm-kubernetes-worker: | |
assignee: | nobody → Adam Dyess (addyess) |
Changed in charm-kubernetes-master: | |
assignee: | nobody → Adam Dyess (addyess) |
This likely only occurs when the charm unit is RECONCILED yet has a blocked or waiting status.
If the charm wasn't reconciled -- an update-status event would force the charm back through the reconciler
However, because it's reconciled, only actionable juju events (relation-*, config-changed, etc.) would force us back through the reconciler.
Action events aren't reconciled -- and therefore they shouldn't really run inside a `status.context`