Open Stack

A review has been posted allowing proper upgrades to the Keystone paste
file in grenade, and the XML references have been removed for the upgrade
case [1]. There is also documentation in the Kilo Release Notes detailing
the upgrade process for XML removal from Juno to Kilo [2].

[1] https://review.openstack.org/#/c/139051/
[2] https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Upgrade_Notes

On Wed, Dec 3, 2014 at 10:26 AM, Sean Dague <sean at dague.net> wrote:

> 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
>
> _______________________________________________
> 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/20141205/49341426/attachment.html>