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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
