Open Stack

So how does rootwrap fit into the "theory of upgrade"?

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

--

Stepping back, I feel like an "expand-contract" style upgrade process
involving rootwrap should look something like
0. Update rootwrap to be the union of N and N+1 rootwrap filters,
1. Rolling update from N to N+1 code,
2. Remove N-only rootwrap entries.

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:
0. Install rootwrap filters from N+1
1. Rolling update to N+1 code

--

So: We obviously need to update rootwrap filters at *some* point, and we
should actually decide when that is.

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.

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.

Thoughts?

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160623/86975c80/attachment.html>