On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague <s...@dague.net> wrote: > 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 made an attempt to capture some of the information on the specific grenade case we were hitting for XML removal in a bug report [1]. We can keep the classes in keystone/middleware/core.py as a workaround for now with essentially another deprecation message, but at some point we should pull the plug on defining XmlBodyMiddleware in our keystone-paste.ini [2] as it won't do anything anyway and shouldn't be in the configuration. Since this deals with a configuration change, this could "always" break a customer. What criteria should we follow for cases like this?
>From visiting with Sean in -qa, typically service configurations don't change for the grenade target on upgrade, but if we have to make a change on upgrade (to clean out old cruft for example), how do we go about that? [1] https://bugs.launchpad.net/grenade/+bug/1398833 [2] https://github.com/openstack/keystone/blob/d82a3caa329e9b42c588e28f694bf847261d63d1/etc/keystone-paste.ini#L15-L22 > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
