RE: Upgrading charms to 16.01
Hi Pshem On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: > I've tried to upgrade keystone to the new charm version (from liberty). > I've updated the source: > > juju set keystone openstack-origin=cloud:trusty-mitaka > > and scheduled an upgrade: > > juju upgrade charm keystone > > but the charm upgrade fails: > > 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive OpenStack > version for codename: mitaka > > What am I doing wrong? > You need to upgrade the charm first, and then set the configuration option as the old version of the charm does not know about mitaka. You can resolve this by doing: juju upgrade-charm --force keystone juju resolved --retry keystone/0 (or whatever the unit name is that failed) Hopefully that should fix you up. Cheers James -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01
This is what I get: ubuntu@maascontroller:~$ juju upgrade-charm --force keystone 2016/01/29 10:43:02 warning: discarding cookies in invalid format (error: json: cannot unmarshal object into Go value of type []cookiejar.entry) 2016/01/29 10:43:04 warning: discarding cookies in invalid format (error: json: cannot unmarshal object into Go value of type []cookiejar.entry) ERROR already running latest charm "cs:trusty/keystone-33" This is a staging environment, but I'd prefer not to wipe it away if possible. Should I force-downgrade it first and then try again? kind regards Pshem On Fri, 29 Jan 2016 at 10:46 James Page wrote: > Hi Pshem > > On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: > >> I've tried to upgrade keystone to the new charm version (from liberty). >> I've updated the source: >> >> juju set keystone openstack-origin=cloud:trusty-mitaka >> >> and scheduled an upgrade: >> >> juju upgrade charm keystone >> >> but the charm upgrade fails: >> >> 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive >> OpenStack version for codename: mitaka >> >> What am I doing wrong? >> > > You need to upgrade the charm first, and then set the configuration option > as the old version of the charm does not know about mitaka. > > You can resolve this by doing: > > juju upgrade-charm --force keystone > juju resolved --retry keystone/0 (or whatever the unit name is that failed) > > Hopefully that should fix you up. > > Cheers > > James > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01
Ok, force-downgrade doesn't seem to work: ubuntu@maascontroller:~$ juju upgrade-charm keystone ERROR already running latest charm "cs:trusty/keystone-33" ubuntu@maascontroller:~$ juju upgrade-charm --force keystone ERROR already running latest charm "cs:trusty/keystone-33" I ended up removing each unit and re-adding it. This has resolved the keystone issue. I have tried that method with another charm (glance): ubuntu@maascontroller:~$ juju set glance openstack-origin=cloud:trusty-mitaka ubuntu@maascontroller:~$ juju upgrade-charm --force glance Added charm "cs:trusty/glance-30" to the environment. that has resulted in exactly the same error: 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive OpenStack version for codename: mitaka 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 hook "config-changed" failed: exit status 1 So I think the only way is to blew away a service unit and deploy a new one. kind regards Pshem On Fri, 29 Jan 2016 at 10:49 James Page wrote: > > Hi Pshem > > On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: > >> I've tried to upgrade keystone to the new charm version (from liberty). >> I've updated the source: >> >> juju set keystone openstack-origin=cloud:trusty-mitaka >> >> and scheduled an upgrade: >> >> juju upgrade charm keystone >> >> but the charm upgrade fails: >> >> 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive >> OpenStack version for codename: mitaka >> >> What am I doing wrong? >> > > You need to upgrade the charm first, and then set the configuration option > as the old version of the charm does not know about mitaka. > > You can resolve this by doing: > > juju upgrade-charm --force keystone > juju resolved --retry keystone/0 (or whatever the unit name is that failed) > > Hopefully that should fix you up. > > Cheers > > James > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01
Pshem, I'm curious if switching would work for you... e.g. juju upgrade-charm --switch cs:trusty/glance-29 Thanks, Billy On Thu, Jan 28, 2016 at 3:43 PM, Pshem Kowalczyk wrote: > Ok, > > force-downgrade doesn't seem to work: > ubuntu@maascontroller:~$ juju upgrade-charm keystone > > > > ERROR already running latest charm "cs:trusty/keystone-33" > ubuntu@maascontroller:~$ juju upgrade-charm --force keystone > ERROR already running latest charm "cs:trusty/keystone-33" > > I ended up removing each unit and re-adding it. This has resolved the > keystone issue. > > I have tried that method with another charm (glance): > > ubuntu@maascontroller:~$ juju set glance > openstack-origin=cloud:trusty-mitaka > ubuntu@maascontroller:~$ juju upgrade-charm --force glance > Added charm "cs:trusty/glance-30" to > the environment. > > that has resulted in exactly the same error: > 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive OpenStack > version for codename: mitaka > 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 hook > "config-changed" failed: exit status 1 > > So I think the only way is to blew away a service unit and deploy a new > one. > > kind regards > Pshem > > > On Fri, 29 Jan 2016 at 10:49 James Page wrote: > >> >> Hi Pshem >> >> On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: >> >>> I've tried to upgrade keystone to the new charm version (from liberty). >>> I've updated the source: >>> >>> juju set keystone openstack-origin=cloud:trusty-mitaka >>> >>> and scheduled an upgrade: >>> >>> juju upgrade charm keystone >>> >>> but the charm upgrade fails: >>> >>> 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive >>> OpenStack version for codename: mitaka >>> >>> What am I doing wrong? >>> >> >> You need to upgrade the charm first, and then set the configuration >> option as the old version of the charm does not know about mitaka. >> >> You can resolve this by doing: >> >> juju upgrade-charm --force keystone >> juju resolved --retry keystone/0 (or whatever the unit name is that >> failed) >> >> Hopefully that should fix you up. >> >> Cheers >> >> James >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- Billy Olsen billy.ol...@canonical.com Software Engineer Canonical USA -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01
On Fri, Jan 29, 2016 at 9:43 AM Pshem Kowalczyk wrote: > Ok, > > force-downgrade doesn't seem to work: > ubuntu@maascontroller:~$ juju upgrade-charm keystone > > > > ERROR already running latest charm "cs:trusty/keystone-33" > ubuntu@maascontroller:~$ juju upgrade-charm --force keystone > ERROR already running latest charm "cs:trusty/keystone-33" > > I ended up removing each unit and re-adding it. This has resolved the > keystone issue. > > I have tried that method with another charm (glance): > > ubuntu@maascontroller:~$ juju set glance > openstack-origin=cloud:trusty-mitaka > ubuntu@maascontroller:~$ juju upgrade-charm --force glance > Added charm "cs:trusty/glance-30" to > the environment. > > that has resulted in exactly the same error: > 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive OpenStack > version for codename: mitaka > 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 hook > "config-changed" failed: exit status 1 > > So I think the only way is to blew away a service unit and deploy a new > one. > James' point above was that you need to upgrade the charm *before* you set the config to use mitaka. The error you are seeing above is on config-changed before the charm upgrade even happens, as the old charm doesn't know about mitaka. If you haven't already blown away your glance service, you can set the openstack-origin back for glance, resolve the config-changed error, then do the upgrade first.. > > kind regards > Pshem > > > On Fri, 29 Jan 2016 at 10:49 James Page wrote: > >> >> Hi Pshem >> >> On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: >> >>> I've tried to upgrade keystone to the new charm version (from liberty). >>> I've updated the source: >>> >>> juju set keystone openstack-origin=cloud:trusty-mitaka >>> >>> and scheduled an upgrade: >>> >>> juju upgrade charm keystone >>> >>> but the charm upgrade fails: >>> >>> 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive >>> OpenStack version for codename: mitaka >>> >>> What am I doing wrong? >>> >> >> You need to upgrade the charm first, and then set the configuration >> option as the old version of the charm does not know about mitaka. >> >> You can resolve this by doing: >> >> juju upgrade-charm --force keystone >> juju resolved --retry keystone/0 (or whatever the unit name is that >> failed) >> >> Hopefully that should fix you up. >> >> Cheers >> >> James >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01
I worked it out as well :-) My final workflow is this (for charms that support the openstack-upgrade action): 1. Set the managed upgrade flag action-managed-upgrade=true 2. upgrade the charm: juju upgrade-charm 3. Set new origin openstack-origin=cloud:trusty-mitaka 4. uprade each unit juju action do unit/0 openstack-upgrade kind regards Pshem On Fri, 29 Jan 2016 at 12:34 Michael Nelson wrote: > On Fri, Jan 29, 2016 at 9:43 AM Pshem Kowalczyk wrote: > >> Ok, >> >> force-downgrade doesn't seem to work: >> ubuntu@maascontroller:~$ juju upgrade-charm keystone >> >> >> >> ERROR already running latest charm "cs:trusty/keystone-33" >> ubuntu@maascontroller:~$ juju upgrade-charm --force keystone >> ERROR already running latest charm "cs:trusty/keystone-33" >> >> I ended up removing each unit and re-adding it. This has resolved the >> keystone issue. >> >> I have tried that method with another charm (glance): >> >> ubuntu@maascontroller:~$ juju set glance >> openstack-origin=cloud:trusty-mitaka >> ubuntu@maascontroller:~$ juju upgrade-charm --force glance >> Added charm "cs:trusty/glance-30" to >> the environment. >> >> that has resulted in exactly the same error: >> 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive >> OpenStack version for codename: mitaka >> 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 >> hook "config-changed" failed: exit status 1 >> >> So I think the only way is to blew away a service unit and deploy a new >> one. >> > > James' point above was that you need to upgrade the charm *before* you set > the config to use mitaka. The error you are seeing above is on > config-changed before the charm upgrade even happens, as the old charm > doesn't know about mitaka. > > If you haven't already blown away your glance service, you can set the > openstack-origin back for glance, resolve the config-changed error, then do > the upgrade first.. > > >> >> kind regards >> Pshem >> >> >> On Fri, 29 Jan 2016 at 10:49 James Page wrote: >> >>> >>> Hi Pshem >>> >>> On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: >>> I've tried to upgrade keystone to the new charm version (from liberty). I've updated the source: juju set keystone openstack-origin=cloud:trusty-mitaka and scheduled an upgrade: juju upgrade charm keystone but the charm upgrade fails: 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive OpenStack version for codename: mitaka What am I doing wrong? >>> >>> You need to upgrade the charm first, and then set the configuration >>> option as the old version of the charm does not know about mitaka. >>> >>> You can resolve this by doing: >>> >>> juju upgrade-charm --force keystone >>> juju resolved --retry keystone/0 (or whatever the unit name is that >>> failed) >>> >>> Hopefully that should fix you up. >>> >>> Cheers >>> >>> James >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01 - Ceph
Is upgrading ceph from one source to the other supported as well, or does the source only work for new deployments? I did this: ubuntu@maascontroller:~$ juju upgrade-charm ceph Added charm "cs:trusty/ceph-43" to the environment. and then: ubuntu@maascontroller:~$ juju set ceph source=cloud:trusty-mitaka but that didn't really upgrade ceph (monitors in my case): root@juju-machine-0-lxc-0:~# ceph -v ceph version 0.94.5 (9764da52395923e0b32908d83a9f7304401fee43) root@juju-machine-0-lxc-0:~# dpkg -l | grep ceph ii ceph 0.94.5-0ubuntu0.15.10.1~cloud0 amd64 distributed storage and file system ii ceph-common 0.94.5-0ubuntu0.15.10.1~cloud0 amd64 common utilities to mount and interact with a ceph storage cluster ii libcephfs1 0.94.5-0ubuntu0.15.10.1~cloud0 amd64 Ceph distributed file system client library ii python-ceph 0.94.5-0ubuntu0.15.10.1~cloud0 all Meta-package for python libraries for the Ceph libraries ii python-cephfs0.94.5-0ubuntu0.15.10.1~cloud0 amd64 Python libraries for the Ceph libcephfs library I've jumped onto each machine and manually updated the source to: deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/mitaka main and then dist-upgraded the machine and it updated as expected to 9.2: root@juju-machine-0-lxc-0:~# ceph -v ceph version 9.2.0 (bb2ecea240f3a1d525bcb35670cb07bd1f0ca299) On Fri, 29 Jan 2016 at 13:15 Pshem Kowalczyk wrote: > > I worked it out as well :-) > > My final workflow is this (for charms that support the openstack-upgrade > action): > > 1. Set the managed upgrade flag > action-managed-upgrade=true > 2. upgrade the charm: > juju upgrade-charm > 3. Set new origin > openstack-origin=cloud:trusty-mitaka > 4. uprade each unit > juju action do unit/0 openstack-upgrade > > kind regards > Pshem > > > On Fri, 29 Jan 2016 at 12:34 Michael Nelson > wrote: > >> On Fri, Jan 29, 2016 at 9:43 AM Pshem Kowalczyk >> wrote: >> >>> Ok, >>> >>> force-downgrade doesn't seem to work: >>> ubuntu@maascontroller:~$ juju upgrade-charm keystone >>> >>> >>> >>> ERROR already running latest charm "cs:trusty/keystone-33" >>> ubuntu@maascontroller:~$ juju upgrade-charm --force keystone >>> ERROR already running latest charm "cs:trusty/keystone-33" >>> >>> I ended up removing each unit and re-adding it. This has resolved the >>> keystone issue. >>> >>> I have tried that method with another charm (glance): >>> >>> ubuntu@maascontroller:~$ juju set glance >>> openstack-origin=cloud:trusty-mitaka >>> ubuntu@maascontroller:~$ juju upgrade-charm --force glance >>> Added charm "cs:trusty/glance-30" to >>> the environment. >>> >>> that has resulted in exactly the same error: >>> 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive >>> OpenStack version for codename: mitaka >>> 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 >>> hook "config-changed" failed: exit status 1 >>> >>> So I think the only way is to blew away a service unit and deploy a new >>> one. >>> >> >> James' point above was that you need to upgrade the charm *before* you >> set the config to use mitaka. The error you are seeing above is on >> config-changed before the charm upgrade even happens, as the old charm >> doesn't know about mitaka. >> >> If you haven't already blown away your glance service, you can set the >> openstack-origin back for glance, resolve the config-changed error, then do >> the upgrade first.. >> >> >>> >>> kind regards >>> Pshem >>> >>> >>> On Fri, 29 Jan 2016 at 10:49 James Page wrote: >>> Hi Pshem On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk wrote: > I've tried to upgrade keystone to the new charm version (from > liberty). I've updated the source: > > juju set keystone openstack-origin=cloud:trusty-mitaka > > and scheduled an upgrade: > > juju upgrade charm keystone > > but the charm upgrade fails: > > 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive > OpenStack version for codename: mitaka > > What am I doing wrong? > You need to upgrade the charm first, and then set the configuration option as the old version of the charm does not know about mitaka. You can resolve this by doing: juju upgrade-charm --force keystone juju resolved --retry keystone/0 (or whatever the unit name is that failed) Hopefully that should fix you up. Cheers James -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> -- Juju mailing list Juju@lists.ubuntu
Re: Upgrading charms to 16.01 - Ceph
Hi Pshem, I've seen that bug too and just tested a kilo to liberty upgrade in my lab. So, I've submitted a bug report here: https://bugs.launchpad.net/charms/+source/ceph/+bug/1540376 Feel free to add to it. On 29 January 2016 at 02:17, Pshem Kowalczyk wrote: > > Is upgrading ceph from one source to the other supported as well, or does > the source only work for new deployments? > > I did this: > ubuntu@maascontroller:~$ juju upgrade-charm ceph > Added charm "cs:trusty/ceph-43" to the environment. > > and then: > ubuntu@maascontroller:~$ juju set ceph source=cloud:trusty-mitaka > > but that didn't really upgrade ceph (monitors in my case): > root@juju-machine-0-lxc-0:~# ceph -v > ceph version 0.94.5 (9764da52395923e0b32908d83a9f7304401fee43) > > root@juju-machine-0-lxc-0:~# dpkg -l | grep ceph > ii ceph 0.94.5-0ubuntu0.15.10.1~cloud0 > amd64distributed storage and file system > ii ceph-common 0.94.5-0ubuntu0.15.10.1~cloud0 > amd64common utilities to mount and interact with a ceph storage > cluster > ii libcephfs1 0.94.5-0ubuntu0.15.10.1~cloud0 > amd64Ceph distributed file system client library > ii python-ceph 0.94.5-0ubuntu0.15.10.1~cloud0 all > Meta-package for python libraries for the Ceph libraries > ii python-cephfs0.94.5-0ubuntu0.15.10.1~cloud0 > amd64Python libraries for the Ceph libcephfs library > > I've jumped onto each machine and manually updated the source to: > deb http://ubuntu-cloud.archive.canonical.com/ubuntu > trusty-updates/mitaka main > > and then dist-upgraded the machine and it updated as expected to 9.2: > > root@juju-machine-0-lxc-0:~# ceph -v > ceph version 9.2.0 (bb2ecea240f3a1d525bcb35670cb07bd1f0ca299) > > > > On Fri, 29 Jan 2016 at 13:15 Pshem Kowalczyk wrote: > >> >> I worked it out as well :-) >> >> My final workflow is this (for charms that support the openstack-upgrade >> action): >> >> 1. Set the managed upgrade flag >> action-managed-upgrade=true >> 2. upgrade the charm: >> juju upgrade-charm >> 3. Set new origin >> openstack-origin=cloud:trusty-mitaka >> 4. uprade each unit >> juju action do unit/0 openstack-upgrade >> >> kind regards >> Pshem >> >> >> On Fri, 29 Jan 2016 at 12:34 Michael Nelson >> wrote: >> >>> On Fri, Jan 29, 2016 at 9:43 AM Pshem Kowalczyk >>> wrote: >>> Ok, force-downgrade doesn't seem to work: ubuntu@maascontroller:~$ juju upgrade-charm keystone ERROR already running latest charm "cs:trusty/keystone-33" ubuntu@maascontroller:~$ juju upgrade-charm --force keystone ERROR already running latest charm "cs:trusty/keystone-33" I ended up removing each unit and re-adding it. This has resolved the keystone issue. I have tried that method with another charm (glance): ubuntu@maascontroller:~$ juju set glance openstack-origin=cloud:trusty-mitaka ubuntu@maascontroller:~$ juju upgrade-charm --force glance Added charm "cs:trusty/glance-30" to the environment. that has resulted in exactly the same error: 2016-01-28 22:40:39 ERROR juju-log FATAL ERROR: Could not derive OpenStack version for codename: mitaka 2016-01-28 22:40:39 ERROR juju.worker.uniter.operation runhook.go:107 hook "config-changed" failed: exit status 1 So I think the only way is to blew away a service unit and deploy a new one. >>> >>> James' point above was that you need to upgrade the charm *before* you >>> set the config to use mitaka. The error you are seeing above is on >>> config-changed before the charm upgrade even happens, as the old charm >>> doesn't know about mitaka. >>> >>> If you haven't already blown away your glance service, you can set the >>> openstack-origin back for glance, resolve the config-changed error, then do >>> the upgrade first.. >>> >>> kind regards Pshem On Fri, 29 Jan 2016 at 10:49 James Page wrote: > > Hi Pshem > > On Thu, 28 Jan 2016 at 22:39 Pshem Kowalczyk > wrote: > >> I've tried to upgrade keystone to the new charm version (from >> liberty). I've updated the source: >> >> juju set keystone openstack-origin=cloud:trusty-mitaka >> >> and scheduled an upgrade: >> >> juju upgrade charm keystone >> >> but the charm upgrade fails: >> >> 2016-01-28 21:36:13 ERROR juju-log FATAL ERROR: Could not derive >> OpenStack version for codename: mitaka >> >> What am I doing wrong? >> > > You need to upgrade the charm first, and then set the configuration > option as the old version of the charm does not know about mitaka. > > You can resolve this by doing: > > juju upgrade-charm --force keystone > juju resolved --retry keystone/0 (or whatever the unit name is t
Re: Upgrading charms to 16.01 - Ceph
On Mon, 1 Feb 2016 at 15:04 Darryl Weaver wrote: > I've seen that bug too and just tested a kilo to liberty upgrade in my lab. > So, I've submitted a bug report here: > https://bugs.launchpad.net/charms/+source/ceph/+bug/1540376 > Currently the behaviour of changing the source config option on the ceph* charms is not equivalent to changing the openstack-origin option on the OpenStack charms. I've commented on Darryl's bug report with a proposed solution of using a upgrade action to allow an upgrade to be rolled across units within a cluster, rather than changing the config causing an upgrade on all units in parallel, allowing for an upgrade without and outage in the cluster. Regards James -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01 - Ceph
Hi Darryl On Wed, 3 Feb 2016 at 00:39 Darryl Weaver wrote: > This would therefore have implications for co-locating nova-compute with > ceph charms on physical nodes. > Upgrading nova-compute would update the apt repository regardless of what > the ceph charm is doing. > Yes - this is one of the drawbacks of pushing two services onto the same underlying machine. Fortunately in this case, only the ceph binaries on disk are updated by the package upgrade - the package maintainer scripts are explicitly configured to not restart ceph services, so that this can have appropriate rolling restart orchestration. > Presumably ceph would then upgrade the next time config-changed hook runs? > I was thinking more along the lines of: juju set ceph source=cloud:trusty-liberty # no-op reconfiguration of software sources juju action do ceph/0 upgrade # update && dist-upgrade && restart of services on unit juju action do ceph/1 upgrade juju action do ceph/2 upgrade This is esp. important for moving to >= infernalis where the ceph daemons run as the ceph user instead of root, requiring a filesystem permissions update for the ceph osd filesystems (which could be very slow depending on storage capacity of the cloud). Just as a sidenote; we're doing some work between now and 16.04 that will mean we deprecate the ceph charm in favour of a new 'ceph-mon' charm - this just runs the monitor process for a ceph cluster and can be placed in a LXC container, allowing for better control over physical server resources for the container once Juju makes the move to LXD. So deployments will be ceph-mon + ceph-osd - the storage team are working on a migration approach for existing ceph deployments as part of this plan. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
