More juju upgrade-juju failings
Nicholas Skaggs
nicholas.skaggs at canonical.com
Wed Apr 4 18:13:00 UTC 2018
Sandor, thanks for this perspective! It was really helpful to see how
upgrades went for you in real life, and more importantly, that 2.3.x
seems to have gone smoothly. We'll be carefully watching and monitoring
2.3->2.4 upgrades as the release draws nearer.
Nicholas
On 04/01/2018 04:04 AM, Sandor Zeestraten wrote:
> 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/
> <http://zeestrataca.com/posts/upgrading-juju/>
>
> Regards
> --
> Sandor Zeestraten
>
> On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs
> <nicholas.skaggs at canonical.com <mailto:nicholas.skaggs at 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
> <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/1746265>
> https://bugs.launchpad.net/juju/+bug/1748294
> <https://bugs.launchpad.net/juju/+bug/1748294>
> https://bugs.launchpad.net/juju/+bug/1697936
> <https://bugs.launchpad.net/juju/+bug/1697936>
>
> Regards
> --
> Sandor Zeestraten
>
> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth
> <mark at ubuntu.com <mailto:mark at ubuntu.com>
> <mailto:mark at ubuntu.com <mailto:mark at 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>
> <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-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>
>
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>>"
> >> 17:16:19 INFO juju.api apiclient.go:597
> connection established
> to
>
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>
>
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/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>
> <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-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>
>
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>>"
> >> 17:16:19 INFO juju.api apiclient.go:597
> connection established
> to
>
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api>
>
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api
> <http://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/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>
> <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> <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> <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>
> <http://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>
> <http://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 at lists.ubuntu.com
> <mailto:Juju-dev at lists.ubuntu.com>
> <mailto:Juju-dev at lists.ubuntu.com
> <mailto:Juju-dev at lists.ubuntu.com>>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> <https://lists.ubuntu.com/mailman/listinfo/juju-dev
> <https://lists.ubuntu.com/mailman/listinfo/juju-dev>>
>
>
>
>
More information about the Juju-dev
mailing list