8:50 AM <ev> re-deploying should become a last resort thing. I want us to figure out how to get upgrade-charm working so that we can just say ./juju-deployer/deploy.py upgrade and it pulls in any updates to the charm and the payload code (uncommitted changes included) in the tree
8:50 AM <ev> juju gives us the hooks for this, we just need to wire them up
8:50 AM <ev> and figure out how to handle one of the instances being in an error state
8:51 AM <vila> ev: indeed, that's the part that I don't get (yet) but I understand it's doable and that's it's the way to go
8:51 AM <vila> ev: juju resolved --retry does well for me in the cases I've encountered recently
8:52 AM <vila> ev: but I didn't diagnose properly what was causing them
8:53 AM <ev> vila: if resolved --retry works it's likely a transient failure in the charm
8:53 AM <ev> or a race
8:53 AM — vila nods
8:54 AM <ev> but more specifically I want to handle the case where the code broke, and that's why we're doing the upgrade
8:54 AM <ev> so yeah, resolved --retry might be the best path forward there (until we get bitten by the unforeseen)
