pylibjuju `model.wait_for_idle` observes different application status than `juju status`
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Caner Derici |
Bug Description
I'm debugging some CI where I use python-libjuju's `model.
```
juju status
Model Controller Cloud/Region Version SLA Timestamp
kubeflow uk8sx microk8s/localhost 2.9.32 unsupported 10:21:39-04:00
App Version Status Scale Charm Channel Rev Address Exposed Message
admission-webhook .../notebooks/
custom resource definition "poddefaults.
Unit Workload Agent Address Ports Message
admission-
```
My expectation was that this would raise because the application is in error, but it does not. When I debug and step through the test, I see the app here showing app.status=
This can be recreated by:
* bootstrap juju on a kubernetes cloud >=v1.22
* juju deploy admission-webhook --channel 1.4/stable
* wait for charm to produce the error (the error is because one of the objects it asks Juju to create is deprecated in k8s 1.22)
* try wait_for_idle, such as like this using pytest-operator:
from pytest_
async def test_is_
await ops_test.
)
Changed in juju: | |
assignee: | nobody → Caner Derici (cderici) |
Changed in juju: | |
milestone: | 2.9-next → none |
Changed in juju: | |
status: | Fix Committed → Fix Released |
I don't think this is pylibjuju's fault, it looks like a bug in Juju status.
For some reason Juju is reporting the application status through the api as "active", even though in the `juju status` we see an "error".
Observe that even though the application appears to be in an error state the `juju status error` command does not list the `admission-webhook` application, while the `juju status active` does.
Investigating further why this is happening.