Good point. I missed that.
i) My thought was that 1.6 will follow 1.2, ie create and then attach.
In which case it should be a PUT /servers/id/disks/id
ii) And, if we want to do a create/attach as a single operation, then POST /servers/id/disks is fine too.
Cheers
<k/>
-------- Original Message --------
Subject: Re: [Openstack] Block storage management API (Cloud Disks API)
From: Jay Pipes <jaypi...@gmail.com>
Date: Tue, January 18, 2011 6:18 am
To: ksan...@doubleclix.net
Cc: Vangelis Koukis <vkou...@cslab.ece.ntua.gr>,
openstack@lists.launchpad.net, c...@cslab.ece.ntua.gr
On Mon, Jan 17, 2011 at 8:50 PM, <ksan...@doubleclix.net> wrote:
> Couple of quick observations on the REST semantics :
> a) What is the context of calls in 1.1 ? A user ? Looks like you are
> assuming the context of a user/group that will own both VMs and disks, which
> is fine. Just wanted to make sure that what it is. You might want to
> consider the case for disk sharing (not simultaneously) where a use creates
> a data set and then others attach it
> b) Looks like there is always RW; no RO disks
> c) You could also extend this for volumes; don't think there is any
> difference between a block device and a volume for the kinds of operations
> listed here
> d) yep, 1.4 PUT /servers/id/disks/id is redundant. No need and it is
> error prone
> e) I think 1.6 requires an id ie POST /servers/id/disks/id
> f) Have you looked at OCCI ?
All good points, with one tiny exception. e) POST /servers/id/disks
should not have a trailing id, as a POST call creates the disk's ID,
at least for most REST interfaces. The PUT call, however, would
include the id...
Cheers!
jay
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
