auto-upgrading models
Rick Harding
rick.harding at canonical.com
Tue Apr 26 02:06:12 UTC 2016
The key thing is that soon our path on upgrading models is via model
migration. We should keep that in mind as we think of how best to lead the
user to 'just do the right thing'
On Mon, Apr 25, 2016, 2:38 PM Andrew Wilkins <andrew.wilkins at canonical.com>
wrote:
> On Sat, Apr 23, 2016 at 4:15 AM Eric Snow <eric.snow at canonical.com> wrote:
>
>> In a recent bug I was working on the issue of auto-upgrading models
>> came up. I also ran into this personally not too long ago.
>> Currently, running "juju upgrade-juju -m admin --upload-tools"[1]
>> upgrades the admin model to a new version. To set the version of any
>> other model to the uploaded one, you must do so separately afterward,
>> e.g. "juju upgrade-juju -m default 2.0-rc1.3". [2]
>>
>> The fact that you must upgrade the non-admin model separately is
>> something new with multi-model support. Perhaps it is only something
>> that will throw off folks that have relied on --upload-tools
>> previously and perhaps it is something that we'll just adjust to.
>> However, I wanted to bring the matter up here and identify potential
>> courses of action (not all mutually exclusive):
>>
>> 1. do nothing (rely on users to know to always upgrade juju per-model)
>> 2. clearly point this out in the documentation
>> 3. add a note in the output of "juju upgrade-juju --upload-tools"
>> reminding admins to manually upgrade each model
>> 4. make the "juju is out-of-date" warnings also show up for models
>> relative to the controller
>> 5. auto-upgrade models when the controller is upgraded
>> 6. auto-upgrade but have a flag to not auto-upgrade
>> 7. have a flag to auto-upgrade
>>
>
> Whatever we do, #2 should never be optional.
>
> I would like us to have all of #2, #3, #4, #7. For #3, we could say
> "upgrade each model ... or run `juju upgrade-juju --all-models
> <version-upgraded-to>`".
>
> I don't think this should be restricted to "--upload-tools", but rather
> just upgrading the admin model in general.
>
> Cheers,
> Andrew
>
> FWIW, I don't consider #1 or #5 to be acceptable options. I'm on the
>> fence about #6; it aligns with what I expect would be a better default
>> experience but hesitate to make unrequested changes of that sort by
>> default. So #7 might be more appropriate if the consequences of #6
>> would be too risky. Regardless, I do think the user experience of
>> upgrade-juju could be improved.
>>
>> Thoughts?
>>
>> -eric
>>
>>
>> [1] You can no longer upload tools to any other model than admin.
>> [2] Thankfully, due to some recent work by axw the new version is
>> *available* to all models.
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160426/d82df455/attachment-0001.html>
More information about the Juju-dev
mailing list