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