Great. Thanks Dolph.. On Wed, Oct 22, 2014 at 7:20 PM, Dolph Mathews <dolph.math...@gmail.com> wrote:
> 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 <xche...@gmail.com> > 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 >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev