Thanks very much for the reply.
Really sorry for the late response.

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 

ð  So, you mean there is no way I can work as I want, right ?

But, is it possible to enable that ?

If you noticed, we're trying to enable HDFS in manila:  
That's the main reason I want to emphasize on my driver do not handle share 

Big data users want to have a unify storage when they're working in cloud.
Because instances are not reliable resource in cloud. Put data together with 
instances while making sure data's reliability would be complicated.

The biggest difference between HDFS and all currently backends manila support 
HDFS has different control path and data path.
For a HDFS cluster, it has one name node and multi data nodes.
Client would talk to "name node" first, get data location and then talk to data 
nodes to get data.
   The "Export location" represent "name node" information only.

ð  We can't put any "share-server" in the middle of user instances and HDFS 

But, it do possible to let the HDFS work in the cloud with restrictions

ð  It can only support one  share-network at one time.

This actually restrict the ability of the manila backend, no multi-tenancy at 

We want to use HDFS like this:
Connect users' "share-network" and "HDFS-cluster-network" by router.
Similar to currently generic driver's behavior when 
"connect_share_server_to_tenant_network = False" while no "share-server" exist.
Access control is achieved based on its own user.

We can add some access control based on keystone users and keystone tenants to 
avoid bad users to connect to HDFS cluster at very beginning if that's possible.


From: Ben Swartzlander [mailto:b...@swartzlander.org]
Sent: Wednesday, January 28, 2015 12:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila]Questions about using not handle 
share-servers drivers with "Flat network"

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 
I set for backend1 and create a "Flat network" in neutron with 
subnet with IP range from
I set for backend2 and create a "Flat network" in neutron with 
subnet with IP range from

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 

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
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to