<div dir="ltr">So how does rootwrap fit into the "theory of upgrade"?<div><br></div><div>The doc talks about deprecating config, but is silent on when new required config (rootwrap filters) should be installed.  By virtue of the way the grenade code works (install N from scratch, attempt to run code from N+1), we effectively have a policy that any new configs are installed at some nebulous time *after* the N+1 code is deployed.  In particular, this means a new rootwrap filter needs to be merged a whole release before that rootwrap entry can be used - and anything else is treated as an "exception" (see for example the nova from-* scripts which have basically updated rootwrap for each release).</div><div><br></div><div>--</div><div><br></div><div>Stepping back, I feel like an "expand-contract" style upgrade process involving rootwrap should look something like</div><div>0. Update rootwrap to be the union of N and N+1 rootwrap filters,</div><div>1. Rolling update from N to N+1 code,</div><div>2. Remove N-only rootwrap entries. </div><div><br></div><div>We could make that a bit easier for deployers by having a sensible deprecation policy that requires our own rootwrap filters for each release are already the union of this release and the last (which indeed is already our policy aiui), and then it would just look like:</div><div>0. Install rootwrap filters from N+1</div><div>1. Rolling update to N+1 code</div><div><br></div><div>--</div><div><br></div><div>So: We obviously need to update rootwrap filters at *some* point, and we should actually decide when that is.</div><div><br></div><div>We can stick with the current de-facto "config after code" grenade policy where we use the rootwrap filters from N for code from N+1, but this implies a 6-month lag on any new rootwrap-using code.  I hereby propose we choose a "config before code" where we use the rootwrap filters for N+1 for code from N+1.  This implies that upgrading the rootwrap filters is a necessary precondition for a code upgrade.</div><div><br></div><div>In practice (for grenade) this just means copying any rootwrap filters from the new branch into place before attempting code upgrade.  I presume there would also be a corresponding ops docs impact - but I haven't seen our current published upgrade procedure.</div><div><br></div><div>Thoughts?</div><div><br></div><div> - Gus</div></div>