Ben Hoyt

Yes indeed, thanks @taurus-forever. Closing.

We run a bunch of automated exec tests against real Pebble in CI and don't have any issues there. Closing this for now unless and until we have a recent,...

Agreed this is messy. However, we'd like any refactoring to be driven by actual needs. For example, if we're adding a significant new feature and it's getting in the way,...

This is not going to happen in the Operator Framework. If anything, we could push on Juju for a feature like this, but for now, closing.

Because `defer` means events *may actually* get run on the same charm instance, I'm not sure about just making a change to `Harness` here. We could change `ops` to always...

@sed-i 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 mean that charms are...

I've been doing some more thinking about this and discussing with various folks, and I think I understand the cases where this is problematic for charmers, or at the very...

@jameinel and I discussed this at some length today. His concerns with reinitializing the charm every Juju or deferred event are: 1) We've previously discussed the ability to handle bulk...

@sed-i I've tried to address the `Harness.evaluate_status` issue in https://github.com/canonical/operator/pull/1048. I think that's just a bug in the implementation and it should have always cleared the previous collected statuses. Let...

@sed-i As for your second comment, can you please give a more specific example of how this would happen? Custom events are fired "synchronously" *during* a hook execution, so by...