Penny Gale

@sed-i @Abuelodelanada thanks for the comments and links. The intent of this issue was to see what happened if someone sat down and tried to run tests after checking out...

This ticket can be closed when: 1. Test dependences are documented in CONTRIBUTING.md and in appropriate places in the Discourse docs 2. The same docs point to advice on bootstrapping...

Hrm. `--force` is a destructive command that could get a model into a bad state, so I'm not sure that it is correct to handle this automatically in the framework....

Thx for the comment, @jameinel! `.defer` is a place where I'd be much more comfortable squishing potential errors like this, provided that we responsibly log the squish.

I am good on this approach. The charms added are maintained by trusted teams, and known to be good quality. And we can bug them if they break our CI...

> So the current CI failures here are from a recent merge where we added extra validation on unit names set by charm devs for harness testing. So if we...

> Okay - I think this should be enough to resolve remaining issues on #776. The remaining failure here is that the observability folks have `# type: ignore` comments that...

planned_units was deliberately written to be naive, so that we could piggyback off of bugfixes in Juju core, without creating another potentially out of sync cache of information about the...

@jameinel do you have any thoughts on this? I thought that dying units would drop off of goal state at some point ...

Just as an exercise, here are some possible scenarios: 1. A human operator is tearing down the cloud. In this case, knowing whether a unit is dying helps a lot....