<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 27 Jun 2016 at 12:59 Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 27, 2016 at 02:02:35AM +0000, Angus Lees wrote:<br>
<br>
> ***<br>
> What are we trying to impose on ourselves for upgrades for the present and<br>
> near future (ie: while rootwrap is still a thing)?<br>
> ***<br>
><br>
> A. Sean says above that we do "offline" upgrades, by which I _think_ he<br>
> means a host-by-host (or even global?) "turn everything (on the same<br>
> host/container) off, upgrade all files on disk for that host/container,<br>
> turn it all back on again".  If this is the model, then we can trivially<br>
> update rootwrap files during the "upgrade" step, and I don't see any reason<br>
> why we need to discuss anything further - except how we implement this in<br>
> grenade.<br>
<br>
Yes this one.  You must upgrade everything in the host/container to the same<br>
release at the same time.  For example we do NOT support running nova@liberty<br>
and cinder@mitaka.<br></blockquote><div><br></div><div>Ack.  <span style="line-height:1.5">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).</span></div><div><br></div><div>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".</div><div><br></div><div>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?</div><div><br></div><div> - Gus</div></div></div>