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 
well.

Thanks,
Jake


Ben Swartzlander <b...@swartzlander.org> wrote on 02/13/2015 07:30:57 PM:

> From: Ben Swartzlander <b...@swartzlander.org>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 02/13/2015 07:33 PM
> Subject: Re: [openstack-dev] [Manila] using one Manila service for two 
clouds
> 
> 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 
Manila
> > service that could be used by clients outside of a specific OpenStack
> > cloud?  For example, a shared Manila service that VMs in two clouds 
could
> > 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 -- 
(1)
> > users would need two keystone credentials - a keystone credential in 
the
> > cloud hosting their VM, and then a keystone credential that is used 
with
> > 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 
network.
> >   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-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
__________________________________________________________________________
> 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
> 


__________________________________________________________________________
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

Reply via email to