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@liberty and cinder@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.
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
