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)" > <email@example.com> > 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