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

Mark McLoughlin markmc at redhat.com
Thu May 9 05:33:29 UTC 2013


On Wed, 2013-05-08 at 18:59 +0000, Gabriel Hurley wrote:
> > -----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.

Per-resource does allow you to expose whether a user has permission to
perform an action, though.

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

Yeah, lots of links can be messy. How about URI templates?

Maybe we have them as a /capabilities/templates resource:

  {"templates": [
     {"rel": "server_start_action",
      "href": "http://example.org/v3/servers/{server_uuid}"
     }
  ]}

then just do:

  "links": [
    {"rel": "start", "template": "server_start_action"}
  ]

Just a thought ...

Cheers,
Mark.




More information about the OpenStack-TC mailing list