Great question! 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.
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. 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. Tempest: - Make XML support optional https://review.openstack.org/#/c/126564/ Devstack: - Make XML support optional moving forward https://review.openstack.org/#/c/126672/ - stable/icehouse continue testing XML support https://review.openstack.org/#/c/127641/ Keystone: - Remove XML support from keystone's default paste config (this makes lxml truly a test-requirement) https://review.openstack.org/#/c/130371/ - (Potentially) remove XML support altogether https://review.openstack.org/#/c/125738/ 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). -Dolph On Mon, Oct 20, 2014 at 8:05 AM, Xu (Simon) Chen <[email protected]> wrote: > 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. > > 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. > > My opinion is that if xml_body filters are in the example/default > paste.ini file, lxml should be included in requirements.txt. > > Comments? > > _______________________________________________ > 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
