Leon

> unless instances are very busy and takes them a long time to suspend I suspect the charm-dev blueprint (microk8s, lxd, juju models) is a busy one. > Is the...

Need to figure out: - What kind of metrics (different from the workload metrics). Perhaps keep it delegated to pebble? - How to expose - push (remote write) or pull...

> I don't think git-sync is responsible for synchronizing between instances of itself - why are you doing that? I'm using git-sync for prometheus alert rules: when those are updated,...

Just clarifying in case this was closed for the wrong reason: 1. If we have a charm in error state, it is [impossible](https://bugs.launchpad.net/juju/+bug/2009634) to upgrade it, nor remove it without...

Afaik, we did not end up adding workarounds directly for this. But I do not recall encountering this issue recently.

This issue puts charm authors in an odd position: - If they use harness for development (i.e. before going to manual tests) then they get incorrect feedback about how their...

> I'm not sure I understand this: > > > because under harness they cannot enjoy the benefits of charm re-init. This leads to overcomplicated code. > > This must...

Another facet of this issue is that in harness tests I need to manually clear collected statuses in between parts of the same test: ```python self.harness.update_config(bad_cfg) self.harness.evaluate_status() self.assertIsInstance(self.harness.charm.unit.status, BlockedStatus) #...

This :point_up: also means that custom events would never be able to remediate a status, because we only have the `add_status` interface. For example, if an earlier func adds a...

Thanks @benhoyt! > Custom events are fired "synchronously" during a hook execution, so by the time the collect-status event is executed after the hook is done, things will be in...