<div dir="ltr">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]. <div><br></div><div>[1] <a href="https://review.openstack.org/#/c/139051/">https://review.openstack.org/#/c/139051/</a></div><div>[2] <a href="https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Upgrade_Notes">https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#Upgrade_Notes</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 10:26 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/03/2014 10:57 AM, Lance Bragstad wrote:<br>
><br>
><br>
> On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
><br>
> We've hit two interesting issues this week around multiple projects<br>
> installing into the paste pipeline of a server.<br>
><br>
> 1) the pkg_resources explosion in grenade. Basically ceilometer modified<br>
> swift paste.ini to add it's own code into swift (that's part of normal<br>
> ceilometer install in devstack -<br>
> <a href="https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381" target="_blank">https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381</a><br>
><br>
> This meant when we upgraded and started swift, it turns out that we're<br>
> actually running old ceilometer code. A requirements mismatch caused an<br>
> explosion (which we've since worked around), however demonstrates a<br>
> clear problem with installing code in another project's pipeline.<br>
><br>
> 2) keystone is having issues dropping XML api support. It turns out that<br>
> parts of it's paste pipeline are actually provided by keystone<br>
> middleware, which means that keystone can't provide a sane "this is not<br>
> supported" message in a proxy class for older paste config files.<br>
><br>
><br>
> I made an attempt to capture some of the information on the specific<br>
> grenade case we were hitting for XML removal in a bug report [1]. We can<br>
> keep the classes in keystone/middleware/core.py as a workaround for now<br>
> with essentially another deprecation message, but at some point we<br>
> should pull the plug on defining XmlBodyMiddleware in our<br>
> keystone-paste.ini [2] as it won't do anything anyway and shouldn't be<br>
> in the configuration. Since this deals with a configuration change, this<br>
> could "always" break a customer. What criteria should we follow for<br>
> cases like this?<br>
><br>
> From visiting with Sean in -qa, typically service configurations don't<br>
> change for the grenade target on upgrade, but if we have to make a<br>
> change on upgrade (to clean out old cruft for example), how do we go<br>
> about that?<br>
<br>
</div></div>Add content here -<br>
<a href="https://github.com/openstack-dev/grenade/tree/master/from-juno" target="_blank">https://github.com/openstack-dev/grenade/tree/master/from-juno</a><br>
<br>
Note: you'll get a -2 unless you provide a link to Release Notes<br>
somewhere that highlights this as an Upgrade Impact for users for the<br>
next release.<br>
<div class="HOEnZb"><div class="h5"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>