More juju upgrade-juju failings

Discussion:

Daniel Bidwell

2018-02-27 22:19:13 UTC

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.

--
Daniel Bidwell <***@gmail.com>
--
Juju mailing list
***@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.

Tim Penhey

2018-02-27 22:26:19 UTC

Permalink

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

Post by Daniel Bidwell
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.
bannercontroller:admin/default
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
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
    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
    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 mailing list
***@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.co

Mark Shuttleworth

2018-02-28 07:30:09 UTC

Permalink

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

Post by Tim Penhey
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
juju upgrade-juju -m controller --agent-version 2.3.3
Cheers,
Tim

--
Juju mailing list
***@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listi

Sandor Zeestraten

2018-03-21 16:32:18 UTC

Permalink

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

Post by Mark Shuttleworth
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

unsupported