Thanks for the reply, and you're right - I was interested in was allowing 
people outside of the cloud to use Manila, that is great to hear that is a 
supported use case.  I still have some learning to do around per-tenant 
share servers and per-tenant networks but in general I think it will work 


Ben Swartzlander <> wrote on 02/13/2015 07:30:57 PM:

> From: Ben Swartzlander <>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <>
> Date: 02/13/2015 07:33 PM
> Subject: Re: [openstack-dev] [Manila] using one Manila service for two 
> On 02/13/2015 05:58 PM, Jake Kugel wrote:
> > Hi,
> >
> > this might be a dumb question, is it possible to have a stand-alone 
> > service that could be used by clients outside of a specific OpenStack
> > cloud?  For example, a shared Manila service that VMs in two clouds 
> > both use?
> We've tried to design Manila to not have any hard dependencies on any 
> OpenStack services (except for keystone). The use case is exactly what 
> you suggest -- people should be able to use Manila outside of the cloud 
> if they wish.
> > I am guessing that there would be two drawbacks to this scenario -- 
> > users would need two keystone credentials - a keystone credential in 
> > cloud hosting their VM, and then a keystone credential that is used 
> > the stand-alone Manila service to create a share.  And (2), the shared
> > Manila service wouldn't be able to isolate network traffic for a
> > particular tenant - all users of the service would share the same 
> >   Do these capture the problems with it?
> Possibly yes. I would like to think it would be possible to use 1 
> keystone for both purposes, but I'm not expert on keystone I'm not 
> familiar with what you're trying to do.
> Regarding isolation of network traffic, Manila doesn't actually do that 
> for you. What Manila does is allows you to create per-tenant share 
> servers and connect them to various per-tenant network, assuming the 
> networks are already segmented by something else. That something else 
> doesn't have to be neutron or a cloud, necessarily. As the code is 
> written today, the segmentation is assumed to be either neutron or 
> nova-network based, but it shouldn't be terribly hard to add something 
> else in the future.
> > Thanks,
> > Jake
> >
> >
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> >
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to