Hi Nicholas, Thanks for the input. I wrote up a short blog post about our experiences going from 2.1 to 2.3. Hopefully it provides some feedback and can be helpful for others in the same position.
http://zeestrataca.com/posts/upgrading-juju/ Regards -- Sandor Zeestraten On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > Sandor, re:sharing experiences, if you want to frame some scenarios you've > had trouble with, please feel free to share those. Distilling it down into > a repeatable deployment -> upgrade will help us understand and account for > it. As Tim mentioned, tools like juju-upgrader are generally candidates for > incorporation into juju itself, provided they prove valuable to the > community at large. We always welcome any PR's, but especially so for > improvements that add this functionality. > > Nicholas > > On 03/21/2018 08:43 PM, Tim Penhey wrote: > >> Hi Sandor, >> >> Streamlining upgrades is definitely on the team's road-map. We are aware >> of the juju-upgrader plugin, and will be looking to incorporate some of >> that functionality into the core codebase. >> >> The core team has worked on better upgrade testing as part of our CI, >> which enables more test scenarios to help discover issues between more >> versions. >> >> Cheers, >> Tim >> >> On 22/03/18 05:32, Sandor Zeestraten wrote: >> >>> Is this shared google doc open for external contributors? >>> >>> After spending a while upgrading our 2.1.x environments to 2.3.x and >>> hitting some bugs along the way in staging (see below), I'd agree that >>> the process needs a bit of love and wouldn't mind sharing some >>> experiences. >>> >>> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a >>> couple of episodes back, but I haven't seen it mentioned anywhere else >>> yet. Are those tools supposed to deal with some of these issues and >>> eventually be rolled into juju-core? >>> >>> https://bugs.launchpad.net/juju/+bug/1746265 >>> https://bugs.launchpad.net/juju/+bug/1748294 >>> https://bugs.launchpad.net/juju/+bug/1697936 >>> >>> Regards >>> -- >>> Sandor Zeestraten >>> >>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth <m...@ubuntu.com >>> <mailto:m...@ubuntu.com>> wrote: >>> >>> >>> I think this UX on the upgrade process has obvious problems. Nobody >>> should have to guess at what to do, in which sequence. >>> >>> Can I suggest that we have a shared Google doc to mock up a nice >>> experience starting with the simple command 'juju upgrade' which >>> then >>> walks people through the process, including the distinction between >>> upgrading charms, agents and controllers, as well as the ability to >>> do >>> aerospace-grade upgrades through live migration to newer >>> controllers? >>> >>> Mark >>> >>> On 02/27/2018 11:26 PM, Tim Penhey wrote: >>> > Hi Daniel, >>> > >>> > The issue here is that you are upgrading the default model, not >>> the >>> > controller model itself. >>> > >>> > I think we could make the error messaging more clear, and also >>> have the >>> > command also check the controller version before showing a lot of >>> > baffling output. >>> > >>> > What you need to do is upgrade the controller model first, so >>> either >>> > switch to it or run: >>> > >>> > juju upgrade-juju -m controller --agent-version 2.3.3 >>> > >>> > Cheers, >>> > Tim >>> > >>> > On 28/02/18 11:19, Daniel Bidwell wrote: >>> >> I am running on juju 2.3.3-xenial-amd64 and my controllers are >>> running >>> >> in VMware Vsphere with version 2.3.2. I thought that it would >>> be a >>> >> good thing for me to upgrade the controllers. >>> >> >>> >> I have a controller, "juju switch" generates: >>> >> bannercontroller:admin/default >>> >> >>> >> and juju status generates: >>> >> Model Controller Cloud/Region Version >>> SLA >>> >> default bannercontroller myvscloud/New >>> Datacenter 2.3.2 unsupported >>> >> >>> >> App Version Status Scale Charm Store Rev OS Notes >>> >> >>> >> Unit Workload Agent Machine Public address Ports Message >>> >> >>> >> Machine State DNS Inst id Series AZ Message >>> >> >>> >> doing "juju upgrade-juju --agent-version 2.3.3 --debug" >>> generates: >>> >> >>> >> 17:16:19 INFO juju.cmd supercommand.go:56 running juju [2.3.3 gc >>> go1.9.2] >>> >> 17:16:19 DEBUG juju.cmd supercommand.go:57 args: >>> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", >>> "--agent-version", "2.3.3", "--debug"} >>> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: >>> [10.1.61.239:17070 <http://10.1.61.239:17070>] >>> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed >>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d5 >>> 7eded74c/api >>> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d >>> 57eded74c/api>" >>> >> 17:16:19 INFO juju.api apiclient.go:597 connection established >>> to >>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d5 >>> 7eded74c/api >>> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d >>> 57eded74c/api>" >>> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: >>> [10.1.61.239:17070 <http://10.1.61.239:17070>] >>> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed >>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d5 >>> 7eded74c/api >>> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d >>> 57eded74c/api>" >>> >> 17:16:19 INFO juju.api apiclient.go:597 connection established >>> to >>> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d5 >>> 7eded74c/api >>> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d >>> 57eded74c/api>" >>> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: >>> [10.1.61.239:17070 <http://10.1.61.239:17070>] >>> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed >>> "wss://10.1.61.239:17070/api <http://10.1.61.239:17070/api>" >>> >> 17:16:19 INFO juju.api apiclient.go:597 connection established >>> to "wss://10.1.61.239:17070/api <http://10.1.61.239:17070/api>" >>> >> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 >>> searching for agent binaries with major: 2 >>> >> 17:16:22 INFO cmd upgradejuju.go:363 available agent binaries: >>> >> 2.3.3-artful-amd64 >>> >> 2.3.3-artful-arm64 >>> >> 2.3.3-artful-ppc64el >>> >> 2.3.3-artful-s390x >>> >> 2.3.3-bionic-amd64 >>> >> 2.3.3-bionic-arm64 >>> >> 2.3.3-bionic-ppc64el >>> >> 2.3.3-bionic-s390x >>> >> 2.3.3-centos7-amd64 >>> >> 2.3.3-trusty-amd64 >>> >> 2.3.3-trusty-arm64 >>> >> 2.3.3-trusty-ppc64el >>> >> 2.3.3-trusty-s390x >>> >> 2.3.3-win10-amd64 >>> >> 2.3.3-win2012-amd64 >>> >> 2.3.3-win2012hv-amd64 >>> >> 2.3.3-win2012hvr2-amd64 >>> >> 2.3.3-win2012r2-amd64 >>> >> 2.3.3-win2016-amd64 >>> >> 2.3.3-win2016nano-amd64 >>> >> 2.3.3-win7-amd64 >>> >> 2.3.3-win8-amd64 >>> >> 2.3.3-win81-amd64 >>> >> 2.3.3-xenial-amd64 >>> >> 2.3.3-xenial-arm64 >>> >> 2.3.3-xenial-ppc64el >>> >> 2.3.3-xenial-s390x >>> >> best version: >>> >> 2.3.3 >>> >> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died >>> >> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died >>> >> 17:16:22 DEBUG juju.api monitor.go:35 RPC connection died >>> >> ERROR a hosted model cannot have a higher version than the server >>> model: 2.3.3 > 2.3.2 >>> >> 17:16:22 DEBUG cmd supercommand.go:459 error stack: >>> >> a hosted model cannot have a higher version than the server >>> model: 2.3.3 > 2.3.2 >>> >> github.com/juju/juju/rpc/client.go:149 >>> <http://github.com/juju/juju/rpc/client.go:149>: >>> >> github.com/juju/juju/api/apiclient.go:924 >>> <http://github.com/juju/juju/api/apiclient.go:924>: >>> >> >>> >> >>> >> I am a little baffled at what the problem might be. This >>> controller has no vm associated with it. >>> >> >>> >>> >>> -- >>> 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 >>> <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
