On Wed, Oct 23, 2013 at 7:43 AM, Dimitri Maziuk <dmaziuk@xxxxxxxxxxxxx> wrote: > On 2013-10-22 22:41, Gregory Farnum wrote: > ... > >> Right now, unsurprisingly, the focus of the existing Manila developers >> is on Option 1: it's less work than the others and supports the most >> common storage protocols very well. But as mentioned, it would be a >> pretty poor fit for CephFS > > > I must be missing something, I thought CephFS was supposed to be a > distributed filesystem which to me means option 1 was the point. It's a question of infrastructure and security. 1) For a private cloud with flat networking this would probably be fine, but if you're running per-tenant VLANs then you might not want to plug all 1000 Ceph IPs into each tenant. 2) Each running VM would need to have a good native CephFS client. That means either a working FUSE install with ceph-fuse and its dependencies installed, or a very new Linux kernel — quite different from NFS or CIFS, which every OS in the world has a good client for. 3) Even if we get our multi-tenancy as good as we can make it, a buggy or malicious client will still be able to introduce service interruptions for the tenant in question. (By disappearing without notification, leaving leases to time out; by grabbing locks and refusing to release them; etc.) Nobody wants their cloud to be blamed for a tenant's software issues, and this would cause trouble. 4) As a development shortcut, providing multitenancy via CephFS would be a lot easier if we can trust the client (that is, the hypervisor host) to provide some of the security we need. Make sense, or am I just crazy? :) -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |