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)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
