[openstack-dev] [grenade] upgrades vs rootwrap

Thierry Carrez thierry at openstack.org
Mon Jul 4 11:59:09 UTC 2016


Angus Lees wrote:
> Ack. Ok .. so what's the additional difficulty around config files?  It
> sounds like we can replace all the config files with something
> completely different during the update phase, if we wanted to do so.
> Indeed, it sounds like there isn't even a need to manage a deprecation
> period for config files since there will never be mismatched code+config
> (good, means fewer poorly tested legacy combinations in code).
>
> Specifically, it seems grenade in both doc and code currently describes
> something quite a bit stricter than this.  I think what we want is more
> like "use devstack to deploy old; run/test; **use devstack to deploy
> new** but pointing at existing DB/state_path from old; run/test,
> interact with things created with old, etc".
>
> A solution to our immediate rootwrap issue would be to just copy over
> the rootwrap configs from 'new' during upgrade always, and this
> shouldn't even be controversial.  I can't read body language over email,
> so .. is everyone ok with this?  Why is this not what everyone was
> jumping to suggest before now?

The issue here is that oslo.rootwrap uses config files to determine what 
to allow, but those are not really configuration files as far as the 
application using them is concerned. Those must match the code being 
executed.

So from Grenade perspective, those should really not be considered 
configuration files, but application files. They should be updated 
together with the code. Some distributions ship them in 
/usr/share/$project IIRC to reinforce that point. If anyone adds their 
own filters they would/should do that in separate files (and probably 
separate directories).

So you can hardcode that subtle distinction in Grenade (copy over the 
rootwrap config files from new). We could maybe also move (during 
Newton) rootwrap "config files" into a location that looks less like 
config files and more like code (and make rootwrap magically find that 
location). That way on upgrade rootwrap could use the Mitaka config 
files + the Newton code-like location (allowing both old and new 
commands to run until the Mitaka files are cleaned up). That might be an 
option if we don't want to special-case rootwrap files (the way they 
should always have been special-cased) in Grenade. Making rootwrap find 
that new location without requiring altering its configuration is a bit 
tricky though.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list