[openstack-dev] [Manila]Questions about using not handle share-servers drivers with "Flat network"

Li, Chen chen.li at intel.com
Wed Jan 28 00:39:54 UTC 2015


Hi list,

I have some questions.
Hope can get help from you guys.

Manila has two driver modes.
For handle share server drivers, the share-network is easy to understand.
For not handle share-servers drivers, manila request admin to do everything before manila-share service start, and when the service is running, it only serves requests do not contain "share-network".

I kept confusing about which/why users would create shares without "share-network". Although when working with this kind of driver, the manila-share service can only support one specific network restricted by the backend. But "users" do not know backends, they should always want to create shares with "share-network", because users always want to connect shares to their instances that lives in the cloud with "share-network".

Then I have been told that these shares created without "share-network" are assumed to be used on a "public network".
The "public network" do make a clear explanation about why "share-network" not matter anymore.

But, when I build my cloud with Manila, what I want to do is let backends to serve my "Flat network".

I want to have 2 backends in Manila, both of them are "not handle share-servers drivers".
I set 192.168.6.253 for backend1 and create a "Flat network" in neutron with subnet 192.168.6.0/24 with IP range from 192.168.6.1-192.168.6.252.
I set 192.168.7.253 for backend2 and create a "Flat network" in neutron with subnet 192.168.7.0/24 with IP range from 192.168.7.1-192.168.7.252.

The reason I build  my cloud like this is because I want to do some performance tests on both backends, to compare the two backends.

I think it should not hard to do it, but manila do not support that currently.

So, is this the behavior should work  ?
Or anything else I missed ?

Thanks.
-chen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/56c7aeb3/attachment.html>


More information about the OpenStack-dev mailing list