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@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

Reply via email to