Open Stack

On 01/27/2015 06:39 PM, Li, Chen wrote:
>
> 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 ?
>
>

Manila needs to support backends that can create share servers and 
backends that can't create share servers. We do this because of the 
reality that different storage systems have different capabilities and 
designs, and we don't want to block anything that can reasonably 
described as a shared filesystem from working with Manila.

For the purposes of Manila, a share server is a logically isolated 
instance of a file share server, with its own IP address, routing 
tables, security domain, and name services. Manila only tracks the 
existence of share servers that were created as the result of a 
share-create operation. Share servers created by manila have IP 
addresses assigned by Manila, and can be expected to be deleted by 
Manila sometime after the last share on that share server is deleted. 
Backends that simply create shares on a preexsting storage systems are 
not referred to as share servers and networking concerns for those 
systems are out of scope for Manila.

The reason we distinguish between so-called "flat" and "segmented" 
networks is to accommodate the reality that in the real world, storage 
systems often exist inside labs and datacenters where the network is not 
under the control of the storage admin. This was a key point we 
identified during Juno and one of the major reasons for the network 
rearchitecture during Kilo. If a storage controller is connected into a 
flat subnet it may be able to create share servers on that subnet, but 
nothing more fancy. To participate in multiple subnets some form of 
network virtualization or segmentation is required and oftentimes that's 
not possible either due to lack of support on the storage controller, 
lack of support in the network due to physical or administrative 
limitations, or even lack of sophistication on the part of the deployer 
(don't discount this last one -- the difficulty of getting the network 
right is a major blocker for admins who want to try out Manila).

What flat network means from Manila's perspective is that share servers 
may be created but only on a network predefined by the administrator, 
and not on any tenant-defined network. Connectivity between the tenant 
network and the share server network is considered out of scope for 
Manila. Segmented network means that Manila presumes complete control of 
the network through some powerful plugin such as Neutron such that 
Manila can connect share servers to any network specified by the tenant, 
and Manila assumes responsibility for establishing any needed routes.

In your case if you have a driver that doesn't handle share servers, 
then the network is complete out of scope for Manila. Drivers that don't 
manage share servers have neither flat not segment networking in Manila, 
they have NO networking.

I'll do a followup mail on the UI changes that are coming around share 
networks and the mess that they have become. For now, you just have to 
know that share networks should not be used with drivers that don't 
manage share servers, and they should be used with drivers that do 
manage share servers.

-Ben Swartzlander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150127/1cca6b0b/attachment.html>