Re: More juju upgrade-juju failings
Glad to help. I reported http://pad.lv/1761288 regarding the ability to abort/rollback broken upgrades in order to get out of sticky upgrade situations. Also hope to see a clean up of the UX and the addition of actual dry-run capabilities in http://pad.lv/1638714 We're looking forward to upgrading from 2.3 to 2.4 with ease and confidence! Regards -- Sandor Zeestraten On Wed, Apr 4, 2018 at 8:13 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > 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 pr
Re: More juju upgrade-juju failings
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: >>> >> ModelControllerCloud/Region Version >>> SLA >>> >> default bannercontroller myvsc
Re: More juju upgrade-juju failings
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:
> >> ModelControllerCloud/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
> >>
Re: We are excited to announce the release of Juju 2.2.3!
Hey Burton, Where can I find the docs on these new bundle options (include-file and include-base64) and the --bundle-config option? Have a nice weekend -- Sandor Zeestraten On Fri, Sep 8, 2017 at 9:43 AM, Burton Swan <burton.s...@canonical.com> wrote: > ## New and Improved > > * The remove-machine command has a --keep-instance flag which allows the > cloud instance to be left running when the machine is removed from the Juju > model > > * Bundles can now reference local resources by specifying a relative path > (as can already be done for local charms). > > * Values in local bundles for options and annotations can now specify a > file to be read for the specified value. This is to support charm options > where the value is some structured content, such as a configuration file. > For binary external files, such as binary certificates, there is an option > to base64 encode the contents of the file so it can be used as a string > value. The referenced file can include the path to the file. The file > location is relative to the bundle file location. e.g.: > > applications: > my-app: > charm: some-charm > options: > config: include-file://my-config.yaml > cert: include-base64://my-cert.crt > > * There is a new option for deploying bundles: --bundle-config. This > configuration file needs to be a YAML file, and currently only supports > applications as a top level key. The format of the applications is the same > as applications section in the bundle. Any values specified for an > application in the bundle-config file override those values defined in the > bundle, with the exception of the map type values, where the maps are > merged with preference given to the bundle-config. The purpose of this to > allow the use of a common bundle definition, and have model specific > configuration kept in a separate file. Option and annotation values > specified in the bundle-config file can also use the include-file:// and > include-base64:// directives mentioned above for local bundles. Paths > specified are relative to the bundle-config file. > > > For a list of all bugs fixed in this release, see > https://launchpad.net/juju/+milestone/2.2.3 > > ## How can I get it? > > The best way to get your hands on this release of Juju is to install it as > a snap package (see https://snapcraft.io for more info on snaps). > > snap install juju --classic > > Other packages are available for a variety of platforms. Please see the > online documentation at https://jujucharms.com/docs/ > stable/reference-install > > Those subscribed to a snap channel should be automatically upgraded. If > you’re using the ppa/homebrew, you should see an upgrade available. > > For highlights of this release, please see the documentation at > https://jujucharms.com/docs/2.2/whats-new > > -- > 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
