[openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading
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 -
> 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 . 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 
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?
> 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 Dague
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev