Add retry options to Container methods
If there's a temporary (very short-lived) issue communicating with Pebble, then we generally recommend that charms retry a small number of times (with appropriate pauses between attempts) rather than defer(), return, or error out.
Rather than having every charm implement a retry mechanism, we could add this as an option to the various Container methods (but not the underlying Pebble class), so that we handle this transparently for users.
We'd need to consider when retrying is/is not appropriate, as well as what the retry pattern should be.
Per Madrid discussion, this still seems like a reasonable idea, but needs a bit more charm research and a proof of concept to validate it. And do we want to do it on every method, or just the read/GET/non-mutating ones?
We're going to have a team Charm Tech discussion in The Hague about this. It's an interesting idea, but several of us have hesitations too. Specifically we need to know: does this intermittent failure mode with talking to Pebble actually happen in practice?
Going to close this won't-fix. We've discussed this at two sprints, and it doesn't seem urgent or a big problem.