Open Stack

On Thu, Jun 23, 2016 at 12:19:34AM +0000, Angus Lees wrote:
> 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

I think effectively this is what we've ended up with in the past.

We've had this issue for some time. There have been several releases
where either Cinder drivers or os-brick changes have needed to add
rootwrap changes. Theoretically we _should_ have hit these problems long
ago.

I think the only reason it hasn't come up before is that these changes
are usually for vendor storage backends. So they never got hit in
grenade tests since those use LVM. We have third party CI, but grenade
tests are not a part of that.

The switch to privsep now has really highlighted this gap. I think we
need to make this implied constraint clear and have it documented. To
upgrade we will need to make sure the rootwrap filters are in place
_before_ we perform any upgrades.

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

+1

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

I think we definitely should have this documented somewhere. Not that
most folks will read that documentation, but at least we have it out
there.

> 
> Thoughts?
> 
>  - Gus

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev