limitations to using iscsi rbd-target-api directly in lieu of gwcli

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I am hoping to expose a REST API to a remote client group who would like to do things like:
 
  • Create, List, and Delete RBDs and map them to gateway (make a LUN)
  • Create snapshots, list, delete, and rollback
  • Determine Owner / Active gateway of a given lun
I would run 2-4 nodes running rbd-target-gw and rbd-target-api however client wishes to not use multi-path, wants to connect directly and only to active gateway for that lun

In order to prevent re-inventing the wheel I was hoping to simply expose the rbd-target-api directly to client but am wondering if this is appropriate. 

My concern is that I am taking gwcli out off the picture by using rbd-target-api directly and am wondering if the rbd-target-api on its own is able to propagate changes in the config up to the RADOS configuration object and thus keep all the gateways in sync.

My other thought was to build a simple and limited in scope api which on the backend runs gwcli commands. 

Thank you for clarification on the functionality and appropriate use.

Respectfully,

Wes Dillingham
wdillingham@xxxxxxxxxxx
Site Reliability Engineer IV - Platform Storage / Ceph

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux