yahoo-eng-team team mailing list archive

[Russell Bryant <1084560@xxxxxxxxxxxxxxxxxx>]

This doesn't seem like a bug, but a request for the next version of the
nova API.  We can't change it in the current version.  I have marked the
bug as Opinion/Wishlist (how we mark feature requests).

** Changed in: nova
   Importance: Undecided => Wishlist

** Changed in: nova
       Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1084560

Title:
  Format change in JSON response after nova show command

Status in OpenStack Compute (Nova):
  Opinion

Bug description:
  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"}]}
  	],
  	
  	"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", 
  		.
  		.
  		.
  		.
  	  }
  }

  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.

  Thanks for the attention.

  Best regards!

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1084560/+subscriptions