[openstack-dev] [Manila] CephFS native driver
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:
> 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
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.
More information about the OpenStack-dev