[openstack-tc] [openstack-dev] Proposal for API version discovery

Gabriel Hurley Gabriel.Hurley at nebula.com
Wed May 8 18:59:53 UTC 2013


> -----Original Message-----
> From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
> Sent: Tuesday, May 07, 2013 3:44 PM

> It is relatively easy to include the info at servers/<uuid> however:
> {
>  "features": ["OS-EXT-SRV-ATTR", "os-start-stop"],
>  "server": {
>    "OS-EXT-SRV-ATTR:host": "1169a68456af48238da47b1d5957a714",
>    "OS-EXT-SRV-ATTR:hypervisor_hostname": "fake-mini",
>    "OS-EXT-SRV-ATTR:instance_name": "instance-00000001",
>    "links": [
>      {"rel": "self",
>       "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
> 008cfa10b980"},
>      {"rel": "start",
>       "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
> 008cfa10b980/start"
>       "feature": "os-start-stop"},
>      {"rel": "stop",
>       "href":"http://example.org/v3/servers/009e9aca-b765-11e2-855a-
> 008cfa10b980/stop"
>       "feature": "os-start-stop"}.
>    ]
>   }
> }

Tht perfectly illustrates my biggest concern with doing this on a per-resource basis. The list of "links" gets unconscionably enormous. If I do a "list" call and retrieve 100 instances each with 100 links because you have 20 extensions the whole thing becomes a mess. I think it's much more sane (though less explicit) to understand what's provided by the service and extrapolate that to the individual resources therein.

As Vish said though, that's the Horizon-esque use case. We deal with the problems of lists of things all the time. It doesn't matter so much for one CLI call, but when you've got dozens or hundreds of simultaneous users, and you have to load all that data every time they change pages... that network traffic adds up fast.

These are good concerns and I want to find a direction that addresses them, these are just my concerns with that solution.

All the best,

    - Gabriel




More information about the OpenStack-TC mailing list