Open Stack

On Mon, 27 Jun 2016 at 12:59 Tony Breeds <tony at bakeyournoodle.com> wrote:

> 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.
>

Ack.  Ok .. so what's the additional difficulty around config files?  It
sounds like we can replace all the config files with something completely
different during the update phase, if we wanted to do so.  Indeed, it
sounds like there isn't even a need to manage a deprecation period for
config files since there will never be mismatched code+config (good, means
fewer poorly tested legacy combinations in code).

Specifically, it seems grenade in both doc and code currently describes
something quite a bit stricter than this.  I think what we want is more
like "use devstack to deploy old; run/test; **use devstack to deploy new**
but pointing at existing DB/state_path from old; run/test, interact with
things created with old, etc".

A solution to our immediate rootwrap issue would be to just copy over the
rootwrap configs from 'new' during upgrade always, and this shouldn't even
be controversial.  I can't read body language over email, so .. is everyone
ok with this?  Why is this not what everyone was jumping to suggest before
now?

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160627/1723bac0/attachment.html>