Open Stack

On 06/23/2016 10:07 AM, Sean McGinnis wrote:
> 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.

Are we going to have to do this for every service individually as it
moves to privsep? Or is there a way we can do it common once, take the
hit, and everyone moves forward?

For instance, can we get oslo.rootwrap to make an exception, in code,
for privsep-helper? Thereby not having to touch a config file in etc to
roll forward.

	-Sean

-- 
Sean Dague
http://dague.net