On Thu, Oct 1, 2015 at 3:32 PM, John Spray <jsp...@redhat.com> wrote:
> On Thu, Oct 1, 2015 at 8:36 AM, Deepak Shetty <dpkshe...@gmail.com> wrote: > > > > > > On Thu, Sep 24, 2015 at 7:19 PM, John Spray <jsp...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev