Re: [openstack-dev] [openstack][keystone] why is lxml only in test-requirements.txt?
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
Re: [openstack-dev] [openstack][keystone] why is lxml only in test-requirements.txt?
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] [openstack][keystone] why is lxml only in test-requirements.txt?
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
