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

Sean Dague sean at dague.net
Wed Dec 3 16:26:14 UTC 2014


On 12/03/2014 10:57 AM, Lance Bragstad wrote:
> 
> 
> On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague <sean at dague.net
> <mailto: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? 

Add content here -
https://github.com/openstack-dev/grenade/tree/master/from-juno

Note: you'll get a -2 unless you provide a link to Release Notes
somewhere that highlights this as an Upgrade Impact for users for the
next release.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list