Comment 20 for bug 1946382

We encountered something like this in PS5-beta where we have a model 'stg-harbor' that is running on Kubernetes, and it is trying to deploy 3 different applications:
```
stg-harbor@launchpad-bastion-ps5:~$ jsft
Model Controller Cloud/Region Version SLA Timestamp
stg-harbor prodstack-is-beta k8s-stg-lp/default 2.9.18 unsupported 16:23:12Z

App Version Status Scale Charm Store Channel Rev OS Address Message
harbor-registry waiting 0/1 harbor-registry charmhub edge 8 kubernetes installing agent
harbor-registry-three waiting 0/1 harbor-registry charmhub edge 8 kubernetes installing agent
harbor-registry-two waiting 0/1 harbor-registry charmhub edge 8 kubernetes installing agent

Unit Workload Agent Address Ports Message
harbor-registry-three/0 waiting allocating installing agent
harbor-registry-two/0 waiting allocating installing agent
harbor-registry/0 waiting allocating installing agent
```

Inside the Juju logs we see a lot of lines about:
```
2022-02-24 15:29:16 INFO juju.apiserver.common password.go:100 setting password for "application-harbor-registry-three"
2022-02-24 15:29:19 INFO juju.apiserver.common password.go:100 setting password for "application-harbor-registry-three"
2022-02-24 15:29:22 INFO juju.apiserver.common password.go:100 setting password for "application-harbor-registry-three"
```

Which should be the Juju provisioner trying to create a password for the charm that is going to spin up, and then using that to tell Kubernetes to provision a pod with a given password.
However, it appears to be spinning, and 'kubectl' on that namespace shows only the model-operator pod.
This would indicate that we are getting some sort of error trying to provision, but not actually logging anything associated with it. (maybe the logs are in one of the 'model' logs).