Open Stack

Hey Mauro,

I don't think it is acceptable to change the json representation. If we need a different representation to make xml work, then we will just have to translate back and forth. An alternative (and probably better) option would be to change the json representation but have it also accept and convert the old json representation. We really can't break an interface that people are already using.

And yes, changing the test to actually do a real xml request would be preferrable.

Vish

On Sep 25, 2012, at 12:54 PM, Mauro Rodrigues <maurosr at linux.vnet.ibm.com> wrote:

> Hi guys, how are you doing?
> 
> Well, I'm working on API samples to Cloudpipe extension[1]. To JSON it works just fine, although when using XML it works partially. what do I mean?
> For JSON, when creating a cloudpipe, the response comes with the follow:
> { "instance_id": "8250f384-ee8a-43b7-9eb2-453e5bbdd019" }
> So using XML I was waiting the same information, looking like this:
> 
> <instance_id>ff1f7847-2bd3-4385-9bbe-d273cea01ba4</instance_id>
> 
> Instead I got just a empty string.
> 
> A similar problem occurs when trying to list cloudpipes, to Json we had the follow response:
> {
>    "cloudpipes": [
>        {
>            "project_id": "b7f6d49c12714e96a05fada4aba4ead6",
>            "internal_ip": "10.0.0.2",
>            "public_ip": "192.168.1.100",
>            "public_port": 8000,
>            "state": "running",
>            "instance_id": "8250f384-ee8a-43b7-9eb2-453e5bbdd019",
>            "created_at": "1981-10-20T00:00:00Z"
>        },
>    ]
> }
> 
> For XML only:
> <cloudpipes>
> <cloudpipe/>
> </cloudpipes>
> 
> I opened a bug [2] about this matter and assigned it to myself. I already push a proposal of change to fix this behavior [3], but I'm not sure if it can be accepted cause I change Json's output to the ones bellow:
> 
> - Create a cloudpipe:
> {   'cloudpipe': {
>         "instance_id": "8250f384-ee8a-43b7-9eb2-453e5bbdd019"
>     }
> }
> 
> - List cloudpipes
> {
>    "cloudpipes": [
>        'cloudpipe': {
>            "project_id": "b7f6d49c12714e96a05fada4aba4ead6",
>            "internal_ip": "10.0.0.2",
>            "public_ip": "192.168.1.100",
>            "public_port": 8000,
>            "state": "running",
>            "instance_id": "8250f384-ee8a-43b7-9eb2-453e5bbdd019",
>            "created_at": "1981-10-20T00:00:00Z"
>        },
>    ]
> }
> 
> These changes were inspired by two things:
> 1 - The way how nova/tests/api/openstack/compute/contrib/test_cloudpipe.py test XML (With a json input equal to the one I'm proposing);
> 2 - And  by the way how keypair extension does the job
> 
> So I would like to hear your feedback on it (here or in the code review) and if it's not a good approach suggestions would be great! =)
> 
> 
> My last question about this is: if my suggestion is acceptable should I change or remove nova.tests.api.openstack.compute.contrib.test_cloudpipe:CloudpipesXMLSerializerTest, which only simulates the real world,  by a class that tests xml as  well json? (Making my xml test class inherit json one).
> 
> 
> 
> [1] - https://review.openstack.org/#/c/13286/
> [2] - https://bugs.launchpad.net/nova/+bug/1056242
> [3] - https://review.openstack.org/#/c/13659/
> 
> Thanks all!
> 
> -- 
> Mauro S. M. Rodrigues
> IBM Linux Technology Center
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev