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> 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]
> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed "wss://
> 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"
> >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: [
> 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"
> >> 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"
> >> 17:16:19 INFO  juju.juju api.go:67 connecting to API addresses: [
> 10.1.61.239:17070]
> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed "wss://
> 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"
> >> 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:
> >> 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
> 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

Reply via email to