# Error in the JSON response when executing nova show (with quantum)

Hi everybody,

I'm running Openstack Folsom with quantum.

I have found this problem: when I run the command:

nova --debug show <instance-id>

I think that the JSON message that the system returns is not correct because it does not correspond to a fixed schema:

{"server": { "status": "ACTIVE", "updated": "2012-11-28T16:41:07Z", "hostId": "0d1236ea4d50a064150eba3961c468073b771a524d02f2c1f28c2b32", "OS-EXT-SRV-ATTR:host": "hostA", "addresses": { "private": [{"version": 4, "addr": "10.1.1.6"}], "public": [{"version": 4, "addr": "192.168.0.134"}], "lan02": [{"version": 4, "addr": "10.1.22.3"}], "lan01": [{"version": 4, "addr": "10.1.11.3"}] }, "links": [{"href": "http://hostA.example.com:8774/v2/bcb940507f644777849d1b3c47c6d6c0/servers/be283a48-6379-40c5-b499-f09f165354ab", "rel": "self"}, {"href": "http://hostA.example.com:8774/bcb940507f644777849d1b3c47c6d6c0/servers/be283a48-6379-40c5-b499-f09f165354ab", "rel": "bookmark"}], "key_name": "mazinger", "image": {"id": "21e2e055-53be-4cf0-a025-5564db5bd901", "links": [{"href": "http://hostA.example.com:8774/bcb940507f644777849d1b3c47c6d6c0/images/21e2e055-53be-4cf0-a025-5564db5bd901", "rel": "bookmark"}]}, "OS-EXT-STS:task_state": null, "OS-EXT-STS:vm_state": "active", "OS-EXT-SRV-ATTR:instance_name": "instance-0000001b", "OS-EXT-SRV-ATTR:hypervisor_hostname": "hostA", "flavor": { "id": "2", "links": [{"href": "http://hostA.example.com:8774/bcb940507f644777849d1b3c47c6d6c0/flavors/2", "rel": "bookmark"}] }, "id": "be283a48-6379-40c5-b499-f09f165354ab", "security_groups": [{"name": "default"}], "user_id": "c4e9a7544f764840899b194e2fa10b42", "name": "fenix03", "created": "2012-11-28T16:40:47Z", "tenant_id": "bcb940507f644777849d1b3c47c6d6c0", "OS-DCF:diskConfig": "MANUAL", "accessIPv4": "", "accessIPv6": "", "progress": 0, "OS-EXT-STS:power_state": 1, "config_drive": "", "metadata": {} } }

We can see that in the value field related to the "addresses" key there is an entry for each network at which the server is connected. Each one, has different Key value. So each time the network configuration changes, the schema of the message also changes, making the message unmanageable.

I think it should be something like this:

{"server": { "status": "ACTIVE", "updated": "2012-11-28T16:41:07Z", "hostId": "0d1236ea4d50a064150eba3961c468073b771a524d02f2c1f28c2b32", "OS-EXT-SRV-ATTR:host": "hostA",

"addresses": [
{"name" : "private", [{"version": 4, "addr": "10.1.1.6"}]},
{"name" : "public", [{"version": 4, "addr": "192.168.0.134"}]},
{"name" : "lan02",[{"version": 4, "addr": "10.1.22.3"}]},
{"name" : "lan01" ,[{"version": 4, "addr": "10.1.11.3"}]}
],

{"href": "http://hostA.example.com:8774/bcb940507f644777849d1b3c47c6d6c0/servers/be283a48-6379-40c5-b499-f09f165354ab", "rel": "bookmark"}],
"key_name": "mazinger",
"image": {"id": "21e2e055-53be-4cf0-a025-5564db5bd901",
.
.
.
.
}


}

Am I wrong? Or it is a problem caused by the migration from nova-network to quantum. I ask this because I'm trying to develop a Java client using JSON.

Thanks for the attention.

Best regards!

edit retag close merge delete

Sort by » oldest newest most voted

worth suggesting as something for next version, please go ahead and create a bug report. however, if you are writing a client, you will always to support old nova instances :) i was just worried about making sure it's not a regression between nova-network and quantum.

more

please see the following entry in the api web site - http://api.openstack.org/api-ref.html GET v2/{tenant_id}/servers/{server_id} Lists details for the specified server.

It does show the same construct "addresses": { "private": [ { "addr": "192.168.0.3", "version": 4 } ] }

i can confirm that the latest nova-network has the same construct as well

more

Mmm, I think there has been a misunderstanding.

What I'm trying to say is that I think the construct should be as in my second snippet. I believe this because, as it is now, the fragment of the JSON response under "addresses" doesn't conform to a fixed schema. I found this problem while trying to parse this message programatically. As it is structured now, I can't build an object able to represent the "addresses" element, since every network inside it is parsed as an element of a different type, with the name of the network used as the type.

Without Quantum there's no problem with this, since there will be always 2 networks: "private" and "public". However, with the custom network support that Quantum offers I think that's no longer the case.

That's why I suggested a different construct (putting the name of the network inside a "name"). I believe this is a bug. I'm sorry if this doesn't come very clear. I'm trying to explain it as best as I can; it's a subtle difference. But important for me, since I'm developing a client for Nova.

more