[openstack-dev] [grenade] upgrades vs rootwrap

Tony Breeds tony at bakeyournoodle.com
Mon Jun 27 02:58:22 UTC 2016


On Mon, Jun 27, 2016 at 02:02:35AM +0000, Angus Lees wrote:

> ***
> What are we trying to impose on ourselves for upgrades for the present and
> near future (ie: while rootwrap is still a thing)?
> ***
> 
> A. Sean says above that we do "offline" upgrades, by which I _think_ he
> means a host-by-host (or even global?) "turn everything (on the same
> host/container) off, upgrade all files on disk for that host/container,
> turn it all back on again".  If this is the model, then we can trivially
> update rootwrap files during the "upgrade" step, and I don't see any reason
> why we need to discuss anything further - except how we implement this in
> grenade.

Yes this one.  You must upgrade everything in the host/container to the same
release at the same time.  For example we do NOT support running nova at liberty
and cinder at mitaka.

> B. We need to support a mix of old + new code running on the same
> host/container, running against the same config files (presumably because
> we're updating service-by-service, or want to minimise the
> service-unavailability during upgrades to literally just a process
> restart).  So we need to think about how and when we stage config vs code
> updates, and make sure that any overlap is appropriately allowed for
> (expand-contract, etc).

During the Austin summit we clearly said this wasn't a thing we did.  The
discussion was mostly centered around code but if we're running code that
needs filter $x then it's reasonable to have to install that filter at the
same time.

I can't find those points in the etherpad sessions where I thought it was
discussed.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160627/d8865511/attachment.pgp>


More information about the OpenStack-dev mailing list