On Tue, Jun 11, 2019 at 10:24 AM Wesley Dillingham <wdillingham@xxxxxxxxxxx> wrote: > > Thanks Jason for the info! A few questions: > > "The current rbd-target-api doesn't really support single path LUNs." > > In our testing, using single path LUNs, listing the "owner" of a given LUN and then connecting directly to that gateway yielded stable and well-performing results, obviously, there was a SPOF, however for this use case, that is acceptable (not a root fs of a vm, etc) If a SPOF is acceptable is there a particular reason that single path would not be agreeable? I should clarify: rbd-target-api will configure multiple paths to each LUN regardless. If you only use the single active path, I guess that's OK. > "It currently doesn't have any RBAC style security so I would be weary > about exposing the current REST API to arbitrary users since you would > give them full access to do anything" > > This is also somewhat of a concern but this is a cluster for a single client who already has full ability to manipulate storage on the legacy system and have been okay. Was planning on network segregating the API so only the given client could communicate with it and also having the gateways run a cephx with permissions only to a particular pool (rbd) and implementing a backup system to offload daily snapshots to a different pool or cluster client does not have capabilities on. > > The dashboard feature looks very promising however client would need to interact programmatically, I do intend on experimenting with giving them iscsi role in the nautilus dashboard. I poked at that a bit and am having some trouble getting the dashboard working with iscsi, wondering if the issue is obvious to you: Fair enough, that would be just using yet another REST API on top of the other REST API. > (running 14.2.0 and ceph-iscsi-3.0-57.g4ae4444) > > and configuring the dash as follows: > > ceph dashboard set-iscsi-api-ssl-verification false > ceph dashboard iscsi-gateway-add http://admin:admin@${MY_HOSTNAME}:5000 > systemctl restart ceph-mgr@${MY_HOSTNAME_SHORT}.service > > in the dash block/iscsi/target shows: > > Unsupported `ceph-iscsi` config version. Expected 8 but found 9. > You will need this PR [1] to bump the version support in the dashboard. It should have been backported to Nautilus as part of v14.2.2. > Thanks again. > > > > > > > > ________________________________ > From: Jason Dillaman <jdillama@xxxxxxxxxx> > Sent: Tuesday, June 11, 2019 9:37 AM > To: Wesley Dillingham > Cc: ceph-users@xxxxxxxxxxxxxx > Subject: Re: limitations to using iscsi rbd-target-api directly in lieu of gwcli > > Notice: This email is from an external sender. > > > > On Tue, Jun 11, 2019 at 9:29 AM Wesley Dillingham > <wdillingham@xxxxxxxxxxx> wrote: > > > > 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 > > It currently doesn't have any RBAC style security so I would be weary > about exposing the current REST API to arbitrary users since you would > give them full access to do anything. The Ceph dashboard in Nautilus > (and also improved in the master branch) has lots of hooks to > configure LUNs via the rbd-target-api REST API as another alternative > to look at. > > > 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 > > The current rbd-target-api doesn't really support single path LUNs. > > > 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. > > gwcli just uses rbd-target-api to do the work, and rbd-target-api is > responsible for keeping the gateways in-sync with each other. > > > 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 > > > > -- > Jason [1] https://github.com/ceph/ceph/pull/27448 -- Jason _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |