Open Stack

On Thu, Oct 1, 2015 at 3:32 PM, John Spray <jspray at redhat.com> wrote:

> On Thu, Oct 1, 2015 at 8:36 AM, Deepak Shetty <dpkshetty at gmail.com> wrote:
> >
> >
> > On Thu, Sep 24, 2015 at 7:19 PM, John Spray <jspray at redhat.com> wrote:
> >>
> >> Hi all,
> >>
> >> I've recently started work on a CephFS driver for Manila.  The (early)
> >> code is here:
> >> https://github.com/openstack/manila/compare/master...jcsp:ceph
> >>
> >
> > 1) README says driver_handles_share_servers=True, but code says
> >
> > + if share_server is not None:
> > + log.warning("You specified a share server, but this driver doesn't use
> > that")
>
> The warning is just for my benefit, so that I could see which bits of
> the API were pushing a share server in.  This driver doesn't care
> about the concept of a share server, so I'm really just ignoring it
> for the moment.
>
> > 2) Would it good to make the data_isolated option controllable from
> > manila.conf config param ?
>
> That's the intention.
>
> > 3) CephFSVolumeClient - it sounds more like CephFSShareClient , any
> reason
> > you chose the
> > word 'Volume" instead of Share ? Volumes remind of RBD volumes, hence
> the Q
>
> The terminology here is not standard across the industry, so there's
> not really any right term.  For example, in docker, a
> container-exposed filesystem is a "volume".  I generally use volume to
> refer to a piece of storage that we're carving out, and share to refer
> to the act of making that visible to someone else.  If I had been
> writing Manila originally I wouldn't have called shares shares :-)
>
> The naming in CephFSVolumeClient will not be the same as Manilas,
> because it is not intended to be Manila-only code, though that's the
> first use for it.
>
> > 4) IIUC there is no need to do access_allow/deny in the cephfs usecase ?
> It
> > looks like
> > create_share, put the cephx keyring in client and it can access the
> share,
> > as long as the
> > client has network access to the ceph cluster. Doc says you don't use IP
> > address based
> > access method, so which method is used in case you are using access_allow
> > flow ?
>
> Currently, as you say, a share is accessible to anyone who knows the
> auth key (created a the time the share is created).
>
> For adding the allow/deny path, I'd simply create and remove new ceph
> keys for each entity being allowed/denied.
>

Ok, but how does that map to the existing Manila access types (IP, User,
Cert) ?

thanx,
deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151006/0da54a1d/attachment.html>