On 16 July 2014 18:55, William Reade <[email protected]> wrote:
> On Wed, Jul 16, 2014 at 3:46 AM, Menno Smits <[email protected]> > wrote: > >> OK - points taken. >> >> So taking your ideas and extending them a little, I'm thinking: >> >> - retry upgrade steps on failure (with inter-attempt delay) >> - indicate when there's upgrade problems by setting the machine agent >> status >> - if despite the retries the upgrade won't complete, report this in >> status and keep the agent running but with the restricted API in place and >> most workers not complete (i.e. as if the upgrade is still running). This >> allows "juju status" and "juju ssh" to work unless there's a significant >> upgrade step that hasn't run that prevents them from working. >> >> Does that sound reasonable? >> > > I think that's reasonable, yeah; only caveat is that if we *are* in a > position to roll back the whole upgrade we should do so. For these > measures, I'm thinking more about situations where the state server has > successfully upgraded but some satellite agents have failed. > Absolutely. The above only applies when there is no backup available to roll back to - i.e. when the version being upgraded from didn't support storing backups server side. If there is a backup the machine agent will roll back to the previous version if the upgrade process fails.
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
