Open Stack

We've hit two interesting issues this week around multiple projects
installing into the paste pipeline of a server.

1) the pkg_resources explosion in grenade. Basically ceilometer modified
swift paste.ini to add it's own code into swift (that's part of normal
ceilometer install in devstack -
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381

This meant when we upgraded and started swift, it turns out that we're
actually running old ceilometer code. A requirements mismatch caused an
explosion (which we've since worked around), however demonstrates a
clear problem with installing code in another project's pipeline.

2) keystone is having issues dropping XML api support. It turns out that
parts of it's paste pipeline are actually provided by keystone
middleware, which means that keystone can't provide a sane "this is not
supported" message in a proxy class for older paste config files.


I'm wondering if we need to be a lot more strict about paste
manipulations, and require that all classes in the paste pipeline are
owned by the project in question. They could be proxy classes to
external code, but at least that would allow the project to smooth out
upgrades. Otherwise everything with code in the paste.ini needs to be
atomically upgraded, and we're trying to get away from atomic upgrades.

	-Sean

-- 
Sean Dague
http://dague.net