[openstack-dev] [Manila] using one Manila service for two clouds

Ben Swartzlander ben at swartzlander.org
Sat Feb 14 01:30:57 UTC 2015


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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list