Current handling of failed upgrades is screwy

[David Cheney]

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 <menno.smits at canonical.com> wrote:
>
>
>
> On 16 July 2014 18:55, William Reade <william.reade at canonical.com> wrote:
>>
>> On Wed, Jul 16, 2014 at 3:46 AM, Menno Smits <menno.smits at canonical.com>
>> 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
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>