Jump to: navigation, search

Manila/Kilo Network Changes

< Manila
Revision as of 14:58, 23 October 2014 by Vponomaryov (talk | contribs) (Cross-tenant share servers)


This document is intended to outline the design changes around Manila networking in the Kilo release.

Use Cases

Simple lab config

A manila developer wants to write a driver for a new hardware platform. The hardware exists in a lab plugged into a network switch with no VLAN tagging. The developer has no management access on the switch or router and while he does have management access on the storage controller he doesn't have any physical access to modify cabling. The storage controller is configured with static IP addresses on its management and data interfaces. On the plus side, the developer had gotten the lab administrators to set aside a pool of IP addresses on the same subnet which he can use to create SVMs.

  • Network: flat, single subnet, multiple SVMs
  • Security: none
  • Other considerations: none

POC installation at a customer site

A customer which already uses OpenStack with some commercial storage wants to experiment with Manila to learn about it and evaluate how useful it might be. The customer already owns several storage controllers but they are all in use either in production or in other proofs of concept or test projects in the eval lab. The customer has administrator access to and physical access to all of the revelant equipment but doesn't wish to disturb the existing environment just to do a quick POC. A storage controller will need to be shared, and the shared controller is cabled to a network switch with no VLAN tagging.

  • Network: flat, single subnet, single SVM
  • Security: none
  • Other considerations: none

Enterprise private cloud

An IT department has built a moderately large private cloud to serve various business units in one company. The business units all know about eachother and rely one simple access control to protect data from prying eyes and accidental damage. The main motivation for building a cloud is the "aaS" model which allows IT to be more efficient and responsive. The company is a large user of NAS storage (on commercial storage controllers) and IT wants to roll out Manila in production to begin to offer NASaaS so its userbase can eventually stop using traditional NAS. The IT department has complete control of its network design, physically and logically. Because all of the "tenants" of the private cloud exist within one company a significant amount of infrastructure is shared, including Active Directory, LDAP, and Kerberos, and tenants are not firewalled off from each other in any complete sense.

  • Network: flat, multiple subnets, multiple SVMs
  • Security: tenants should not be able to access shares of other tenants
  • Other considerations: none

Public Cloud Service

A company that offers cloud services to the public, based on OpenStack, would like to deploy Manila in production and begin to offer NASaaS to its customers alongside block and object storage. Tenants expect complete privacy for their data, both in motion and at rest. Some customers have VPN connections between their corporate offices and the cloud which their expect only their own VMs to be able to access.

  • Network: segmented, multiple subnets, multiple SVMs
  • Security: tenants should not be able to detect the existence of others tenants
  • Other considerations: network segmentation may be VLAN, VXLAN, or GRE

Public cloud (Tenant Facilitated)

Tenants desire to fire up and deliver Manila wholly contained within their tenant context atop a public (or potentially private) cloud.

  • Network: flat, VPC, multiple SVMs
  • Security: defined by tenant owner and contained within the context
  • Other considerations: tenant network may reside atop any number of SDN technologies.

Standalone installation for management of existing NAS

An IT department wishes to offer NASaaS to users but currently uses funky proprietary cloud software written by engineers with bad taste. They decide to use Manila but without the rest of the OpenStack. Commercial storage controllers are dedicated specifically for this purpose.

  • Network: flat, multiple subnets, multiple SVMs
  • Security: tenants should not be able to access shares of other tenants
  • Other considerations: none

Automated test system

A manila developer would like to be able to quickly setup Manila inside a virtual environment for testing. Manila and all of the rest of OpenStack will run inside a single VM with network connectivity to the outside world provided by a virtual router. The storage controller to be tested is not virtualized and is shared with multiple test nodes. The developer has access to configure the storage controller but the VM where the tests are being run is in a different locale, connected only by IP to the storage controller.

  • Network: flat, single subnet, single SVM
  • Security: none
  • Other considerations: none

Triple-O "Under Cloud"

A deployer of OpenStack employing Triple-O employees Manila at the under cloud layer to spin up / down storage server instances to facilitate Manila service expansion / contraction. Under cloud provisioning primitives (e.g. NFS export) for Cinder backends or Glance repositories are employed

  • Network: flat, single subnet, multiple share servers
  • Security: TBD
  • Other considerations: TBD

Design Changes

To accommodate the above use cases, the following changes to Manila will be neededː

Cross-tenant share servers

Administrators should have a way to make a single share server usable by multiple tenants, and disable the creation of new share servers. This enables cases where share servers cannot be created by Manila either because of lack of access or lack of networking resources.

Open questionsː

  • How will the share server get imported into Manila? Conf file options? A new admin API?
  • Is there any point in allowing a mix of manila-created share servers with administrator create share servers?


1) Easy
1.1) Add support of single preconfigured share-server for each driver separately. - They will work as single-tenant drivers in case no share-network provided.

proː no need to create share-network conː only one share-server will be used

2) Hard
2.1) Add new APIs for share-server creation and share-server-details update and then link all of it to some share-network and back-end

proː dynamic add of custom share-servers conː hard to support driver-specific things

Cross-tenant share networks

Administrators should have a way to make a single share network usable by multiple tenants. This network is used to create new share servers when the tenant declines to specify a share network (acting as a "default share network").


1) Allow creation of "public" and "private" share-networks
2) Handle possibility to create both types by policies
3) Add possibility to make one of "public" share networks as "default" that will be used if one did not provide share-network explicitly.