On Wed, Apr 6, 2016 at 5:47 AM, <song.baisen@xxxxxxxxxx> wrote:
> Thank you for your reply!
>
>
> /v2/cluster/fsid/pool_id/rbd(get,post)
>
> Shouldnt this be /v2/cluster/{fsid}/pool/{pool-id}/rbd (get,post)
>
> Yes,Here what i want to say is just as you said.Thank you for your advice.
>
> 5
> /v2/cluster/{fsid}/pool/{pool_id}/rbd/{imagename}/snapname(get,patch,delete)
>
> /v2/cluster/{fsid}/pool/{pool-id}/rbd/{name}/snap (why snapname??)
>
> Here use snapname because there may be a lot of snaps under one image.And
> each
> snap have its own operation.
>
>
>
>
>
>
> Shubhendu Tripathi <shtripat@xxxxxxxxxx>
>
> 2016-04-06 17:29
>
> 收件人
> song.baisen@xxxxxxxxxx, gregory.meno@xxxxxxxxxxx, dmick@xxxxxxxxxx,
> sage@xxxxxxxxxxxx,
> 抄送
> ceph-calamari@xxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx
> 主题
> Re: [ceph-calamari] BluePrint:add a rbd restful api for calamari
>
>
>
>
>
> On 04/06/2016 02:52 PM, song.baisen@xxxxxxxxxx wrote:
> Hi, Calamariers and Cephers, nice to meet you all!
>
> Within this email I'd like to share about expanding
> RBD APIs in Python format, which shall be appreciated by Calamari,
> a powerful tool for Ceph management.
>
> Wiki about this BP can be found at the following the link below:
> http://tracker.ceph.com/projects/ceph/wiki/Submissions
> Right now it provides some basic ideas such as motivation，principle，
> and rough developing plannings only but will get continuous updating
> as the discussion goes on.
>
> At present, Calamari has already introduced a RBD restful APIs
> but those APIs are only available in CLI form and these APIs are
> invisible for Cthulhu.For future consider we should develop rbd restful
> APIS like pool APIS in calamari.Ceph have provided the rbd python APIS for
> user to use.We should use the Ceph RBD python APIS better than the CLI form.
> The goal of this BP is to make those APIs visible for Cthulhu also,
> and thus we can perform RBD relevant operations through Calamari,
> which shall be much simpler and convenient, especially for future Calamari
> RBD Web dashboard develop.
>
> The following APIs are currently under my consideration, with which
> we can create an image, delete it, create a snap for it, and so on.
> More APIs are on the way!
>
> 1 /v2/cluster/fsid/rbd(get)
> get: get info of all pools and their containing images.
>
> 2 /v2/cluster/fsid/pool_id/rbd(get,post)
>
> Shouldnt this be /v2/cluster/{fsid}/pool/{pool-id}/rbd (get,post)
>
> get: get info of a specified pool and its containing images
> post: mirror image from a specified pool to another
>
> 3 /v2/cluster/fsid/pool_id/rbd/imagename/clone(get post delete)
>
> I feel it should be /v2/cluster/{fsid}/pool/{pool-id}/rbd/{name}/clone
>
>
> get: get info of a specified image clone
> post:clone this image from this pool to another pool
> delete:flatten the clone image in this pool
>
> 4 /v2/cluster/fsid/pool_id/rbd/imagename(get,patch,delete,post)
>
> /v2/cluster/{fsid}/pool/{pool-id}/rbd/{name} (get,patch,delete,post)
>
> Also additional one could be /v2/cluster/{fsid}/pool/{pool-id}/rbd to list
> all the rbds for the pool
>
> get:get the image detail info
> patch:update the image name and size and so on.
> delete: remove this image
> post: create a snapshot for this image
>
> 5 /v2/cluster/fsid/pool_id/rbd/imagename/snapname(get,patch,delete)
>
> /v2/cluster/{fsid}/pool/{pool-id}/rbd/{name}/snap (why snapname??)
>
> get:get the detail snap info of this image
> patch:update the snap info as protect or not and so on.
> delete:remove this snapshot from the image
>
>
> Thanks!
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s). If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
>
>
>
>
>
> _______________________________________________
> ceph-calamari mailing list
> ceph-calamari@xxxxxxxxxxxxxx
> http://lists.ceph.com/listinfo.cgi/ceph-calamari-ceph.com
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s). If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
>
>
Hello,
Thank for contributing this proposal. I look forward to working with you!
I have a few questions about the proposed URL structure.
1. Have you considered that making image name part of the URL would
allow for extraordinarily long URLs?
2. Would you please share your rationale for putting the image API in
the context of both cluster and pool?
To me the cluster context makes sense but I'm not sure about
the pool. There is no requirement to keep your images in a specifc
pool. I think that it might be a better experience if pool was a field
on an image. i.e. the list view shows all images in the cluster and
each item mentions what pool it lives in.
cheers,
Gregory
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
