How do we get the tools on the new controller? Since we did a fresh bootstrap it won't have the old tools cached. Is part of the pre-flight migration checks ensuring that the new controller can get the right version of tools? How does it work if someone used --upload-tools on the old host? Is there a "migrate and upgrade" mechanism so you can make forward progress?
John =:-> On Apr 26, 2016 06:48, "Tim Penhey" <tim.pen...@canonical.com> wrote: On 26/04/16 14:06, Rick Harding wrote: > 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' Yes and No. A hosted model will never be allowed to upgrade beyond the controller that it is running on. Due to the high potential risk of upgrading the controller and potentially breaking multiple deployed models, migration is the intended process to ALLOW upgrades. The migration of a model from one controller to another will not upgrade the hosted model itself. Consider this scenario: Controller-1 has 20 hosted models. The controller and the models are running Juju 2.2.0. The new hotness of Juju 2.3 has been released and has many new bells and whistles. In order for the hosted environments to upgrade to Juju 2.3, they must be on a controller running Juju 2.3. Since we don't want to upgrade controller-1, we bootstrap a new controller, "controller-2" with Juju 2.3. We can then migration the models from controller-1 to controller-2 on an as needed basis. The models, once on controller-2 will hopefully then inform the users of that model (through status) that an upgrade is possible. The users can then upgrade the model at their leisure. Tim > > > On Mon, Apr 25, 2016, 2:38 PM Andrew Wilkins > <andrew.wilk...@canonical.com <mailto:andrew.wilk...@canonical.com>> wrote: > > On Sat, Apr 23, 2016 at 4:15 AM Eric Snow <eric.s...@canonical.com > <mailto:eric.s...@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@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
