On Tue, Jun 11, 2019 at 10:24 AM Wesley Dillingham <[email protected]> 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 <[email protected]> > Sent: Tuesday, June 11, 2019 9:37 AM > To: Wesley Dillingham > Cc: [email protected] > Subject: Re: [ceph-users] 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 > <[email protected]> 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 > > [email protected] > > Site Reliability Engineer IV - Platform Storage / Ceph > > > > _______________________________________________ > > ceph-users mailing list > > [email protected] > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > -- > Jason [1] https://github.com/ceph/ceph/pull/27448 -- Jason _______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
