<div dir="ltr"><div>Great question!</div><div><br></div>For some backstory, the community interest in supporting XML has always been lackluster, so the XML translation middleware has been on a slow road of decline. It's a burden for everyone to maintain, and only works for certain API calls. For the bulk of Keystone's documented APIs, XML support is largely untested, undocumented, and unsupported. Given all that, I wouldn't recommend anyone deploy the XML middleware unless you *really* need some aspect of it's tested functionality.<div><br></div><div>In both Icehouse and Juno, we shipped the XML translation middleware with a deprecation warning, but kept it in the default pipeline. That was basically my fault, because both Keystone's functional tests and tempest are hardcoded to expect XML support, and we didn't have time during Icehouse to break those expectations... but still wanted to communicate out the fact that XML was on the road to deprecation.</div><div><br></div><div>So, to remedy that, we have now have a bunch of patches (thanks for your help, Lance!) which complete the work we started back in Icehouse.</div><div><br></div><div>Tempest:</div><div>- Make XML support optional <a href="https://review.openstack.org/#/c/126564/">https://review.openstack.org/#/c/126564/</a></div><div><br></div><div>Devstack:</div><div>- Make XML support optional moving forward <a href="https://review.openstack.org/#/c/126672/">https://review.openstack.org/#/c/126672/</a></div><div>- stable/icehouse continue testing XML support <a href="https://review.openstack.org/#/c/127641/">https://review.openstack.org/#/c/127641/</a></div><div><br></div><div><div>Keystone:</div>- Remove XML support from keystone's default paste config (this makes lxml truly a test-requirement) <a href="https://review.openstack.org/#/c/130371/">https://review.openstack.org/#/c/130371/</a></div><div>- (Potentially) remove XML support altogether <a href="https://review.openstack.org/#/c/125738/">https://review.openstack.org/#/c/125738/</a></div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">The patches to Tempest and Devstack should definitely land, and now we need to have a conversation about our desire to continue support for XML in Kilo (i.e. choose from the last two Keystone patches).</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Dolph</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 8:05 AM, Xu (Simon) Chen <span dir="ltr"><<a href="mailto:xchenum@gmail.com" target="_blank">xchenum@gmail.com</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"><div dir="ltr">I am trying to understand why lxml is only in test-requirements.txt... The default pipelines do contain xml_body and xml_body_v2 filters, which depends on lxml to function properly. <div><br></div><div>Since lxml is not in requirements.txt, my packaging system won't include lxml in the deployment drop. At the same time, my environment involves using browsers to directly authenticate with keystone - and browsers (firefox/chrome alike) send "accept: application/xml" in their request headers, which triggers xml_body to perform json to xml conversion, which fails because lxml is not there.</div><div><br></div><div>My opinion is that if xml_body filters are in the example/default paste.ini file, lxml should be included in requirements.txt. </div><div><br></div><div>Comments?</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div></div></div></div>