If that is the blocker. Can we introduce a major version which does not change the schema at all. Then we know that everyone running Juju has a functional backup system. As I understand it, we require people to upgrade in order, without skipping versions.
On Wed, Jul 16, 2014 at 8:32 PM, Menno Smits <[email protected]> wrote: > > > > 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 > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
