Open Stack

On 10/31/2013 07:58 PM, Adam Young wrote:
> On 10/31/2013 03:40 PM, Steven Hardy wrote:
>> Hi all,
>>
>> So firstly, if you're an XML guru, I apologize, the questions below are
>> probably really basic, I always prefer JSON or YAML, because every 
>> time I
>> deal with XML, I get a week-long-headache ;)
>>
>> So I'm writing Tempest API tests for the keystone OS-TRUST extension, as
>> was previously requested - it's going pretty well, & I'm finding some 
>> real
>> bugs.  Here's a WIP review:
>>
>> https://review.openstack.org/#/c/54810/
>>
>> However, I've got a bit stuck formatting the POST body for the trust 
>> create
>> in XML (all works fine via JSON).  The json body looks like:
>>
>> {
>>      "trust": {
>>          "expires_at": "2013-02-27T18:30:59.999999Z",
>>          "impersonation": true,
>>          "project_id": "ddef321",
>>          "roles": [
>>              {
>>                  "name": "member"
>>              }
>>          ],
>>          "trustee_user_id": "86c0d5",
>>          "trustor_user_id": "a0fdfd"
>>      }
>> }
>>
>> And looking at other XML tests which format a POST body, they do 
>> something
>> like:
>>
>> post_body = Element("trust",
>>                      xmlns=XMLNS,
>>                      trustor_user_id=trustor_user_id,
>>                      trustee_user_id=trustee_user_id,
>>                      project_id=project_id,
>>                      impersonation=impersonation,
>>                      expires_at=expires_at)
>>
>> This gives me a post body which looks weird (but seems to work):
>>
>> <trust impersonation="True"
>> xmlns="http://docs.openstack.org/identity/api/v3"
>> trustor_user_id="efc6504105c54fbe95928a51459d06c9" expires_at=""
>> trustee_user_id="f55efd1d617e4367891d202a811d7728"
>> project_id="b5d498f9631244b59912ce2a0025cf8d"/>
>>
>>
>> So my questions are:
>> 1. Why do we create a single element like this, instead of appending
>> subelements so the XML body looks more like the JSON request?
>
> There are two sides. Some would say that the above is more like a JSON 
> map
>
>   ['a':'1','b':'2','c':'3']
>
> compare
>
> <'a':'1','b':'2','c':'3' />
>
> to
>
> <'a'='1'>,<'b'='2'>,<'c'='3'>
>
> And is starts getting even wonkier when the nested element is a 
> map...XML has two abstractions where JSON has one.  THere is no clean 
> way to always map on to the other (IMHO).
>
>>
>> 2. If any elements have a None value, they are encoded as a zero-length
>> string, is that expected?
>>
>> 3. How do I go about encoding the list of roles, as in the sample 
>> request
>> (it's a list of dicts, where each dict has one key called "name")
> That, I think is
>
> <role>
> <"name": "member">
> </role>
>
> However, all of this should be viewable with the existing unit tests.  
> Each API gets run with both JSON and XML.  In the keystone proejct, 
> the test is in tests/test_v3_auth.py
>
> I still use run_test.sh even though it is deprecated
>
> run_tests.sh  keystone.tests.test_v3_auth.TestAuthXML
>
> If you run that in a debugger you should be able to grab the actual 
> XML that gets marshalled.

I think it is safe to say that the trusts API is broken in XML.  I added 
the following test:

diff --git a/keystone/tests/test_v3_auth.py b/keystone/tests/test_v3_auth.py
index c0e191b..6a0c10c 100644
--- a/keystone/tests/test_v3_auth.py
+++ b/keystone/tests/test_v3_auth.py
@@ -2238,3 +2238,7 @@ class TestTrustAuth(TestAuthInfo):
          self.get('/OS-TRUST/trusts?trustor_user_id=%s' %
                   self.user_id, expected_status=401,
                   token=trust_token)
+
+
+class TestTrustAuthXML(TestTrustAuth):
+    content_type = 'xml'

And, when running it, I got:


Ran 24 tests in 5.832s

FAILED (SKIP=1, errors=12)


https://bugs.launchpad.net/keystone/+bug/1246941

>
>
>>
>> Any help, review feedback or pointers to docs/examples would be hugely
>> appreciated!
>>
>> Thanks,
>>
>> Steve
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev