Hi Darryl
On Wed, 3 Feb 2016 at 00:39 Darryl Weaver <dar...@darrylweaver.com> 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
