[openstack-dev] [Manila] CephFS native driver

John Spray jspray at redhat.com
Thu Oct 1 10:02:48 UTC 2015


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.

John



More information about the OpenStack-dev mailing list