<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 24 Jun 2016 at 20:48 Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/24/2016 05:12 AM, Thierry Carrez wrote:<br>> I'm adding Possibility (0): change Grenade so that rootwrap filters from<br>
> N+1 are put in place before you upgrade.<br>
<br>
If you do that as general course what you are saying is that every<br>
installer and install process includes overwriting all of rootwrap<br>
before every upgrade. Keep in mind we do upstream upgrade as offline,<br>
which means that we've fully shut down the cloud. This would remove the<br>
testing requirement that rootwrap configs were even compatible between N<br>
and N+1. And you think this is theoretical, you should see the patches<br>
I've gotten over the years to grenade because people didn't see an issue<br>
with that at all. :)<br>
<br>
I do get that people don't like the constraints we've self imposed, but<br>
we've done that for very good reasons. The #1 complaint from operators,<br>
for ever, has been the pain and danger of upgrading. That's why we are<br>
still trademarking new Juno clouds. When you upgrade Apache, you don't<br>
have to change your config files.<br></blockquote><div><br></div><div>In case it got lost, I'm 100% on board with making upgrades safe and straightforward, and I understand that grenade is merely a tool to help us test ourselves against our process and not an enemy to be worked around.  I'm an ops guy proud and true and hate you all for making openstack hard to upgrade in the first place :P</div><div><br></div><div>Rootwrap configs need to be updated in line with new rootwrap-using code - that's just the way the rootwrap security mechanism works, since the security "trust" flows from the root-installed rootwrap config files.</div><br class="inbox-inbox-Apple-interchange-newline"><div>I would like to clarify what our self-imposed upgrade rules are so that I can design code within those constraints, and no-one is answering my question so I'm just getting more confused as this thread progresses...</div><div><br></div><div>***</div><div>What are we trying to impose on ourselves for upgrades for the present and near future (ie: while rootwrap is still a thing)?</div><div>***</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>C. W<span style="line-height:1.5">e would like to just never upgrade rootwrap (or other config) files ever again (implying a freeze in as_root command lines, effective ~a year ago).  Any config update is an exception dealt with through case-by-case process and release notes.</span></div><div><br></div><div><br></div><div>I feel like the grenade check currently implements (B) with a 6 month lead time on config changes, but the "theory of upgrade" doc and our verbal policy might actually be (C) (see this thread, eg), and Sean above introduced the phrase "offline" which threw me completely into thinking maybe we're aiming for (A).  You can see why I'm looking for clarification  ;)</div><div><br></div><div> - Gus</div></div></div>