[openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

Lance Bragstad lbragstad at gmail.com
Wed Dec 3 15:57:09 UTC 2014


On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/dfaf4ab2/attachment.html>


More information about the OpenStack-dev mailing list