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 <[email protected]> wrote: > On 12/03/2014 10:57 AM, Lance Bragstad wrote: > > > > > > On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague <[email protected] > > <mailto:[email protected]>> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
