<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 9:18 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote><div><br></div><div>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? </div><div><br></div><div>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? </div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/grenade/+bug/1398833">https://bugs.launchpad.net/grenade/+bug/1398833</a></div><div>[2] <a href="https://github.com/openstack/keystone/blob/d82a3caa329e9b42c588e28f694bf847261d63d1/etc/keystone-paste.ini#L15-L22">https://github.com/openstack/keystone/blob/d82a3caa329e9b42c588e28f694bf847261d63d1/etc/keystone-paste.ini#L15-L22</a> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm wondering if we need to be a lot more strict about paste<br>
manipulations, and require that all classes in the paste pipeline are<br>
owned by the project in question. They could be proxy classes to<br>
external code, but at least that would allow the project to smooth out<br>
upgrades. Otherwise everything with code in the paste.ini needs to be<br>
atomically upgraded, and we're trying to get away from atomic upgrades.<br>
<span class=""><font color="#888888"><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>
</font></span></blockquote></div><br></div></div>