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.ska...@canonical.com <mailto: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
<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
<m...@ubuntu.com <mailto:m...@ubuntu.com>
<mailto: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>
<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@lists.ubuntu.com
<mailto:Juju-dev@lists.ubuntu.com>
<mailto: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>
<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
