2014-10-22 08:38:13 -04:00
|
|
|
..
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
|
not use this file except in compliance with the License. You may obtain
|
|
|
|
|
a copy of the License at
|
|
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
|
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
|
|
|
License for the specific language governing permissions and limitations
|
|
|
|
|
under the License.
|
|
|
|
|
|
|
|
|
|
Configure multiple back ends
|
|
|
|
|
============================
|
|
|
|
|
An administrator can configure an instance of Manila to provision shares from
|
|
|
|
|
one or more back ends. Each back end leverages an instance of a vendor-specific
|
|
|
|
|
implementation of the Manila driver API.
|
|
|
|
|
|
|
|
|
|
The name of the back end is declared as a configuration option
|
|
|
|
|
share_backend_name within a particular configuration stanza that contains the
|
|
|
|
|
related configuration options for that back end.
|
|
|
|
|
|
|
|
|
|
Administrators can specify that a particular share type be explicitly
|
|
|
|
|
associated with a single back end by including the extra spec
|
|
|
|
|
share_backend_name with the name specified within the back end configuration
|
|
|
|
|
stanza. When the Manila scheduler receives a provisioning request for a share
|
|
|
|
|
type with this extra spec set, it will fulfill the share provisioning request
|
|
|
|
|
on the specified back end (assuming all other scheduling criteria including
|
|
|
|
|
available capacity are met).
|
|
|
|
|
|
|
|
|
|
Enable multiple back ends
|
|
|
|
|
=========================
|
2015-02-24 13:49:36 -05:00
|
|
|
To enable multiple share back ends, you must set the enabled_share_backends
|
|
|
|
|
flag in the manila.conf file. This flag defines the names (separated by a
|
|
|
|
|
comma) of the configuration stanzas for the different back ends: one name is
|
2014-10-22 08:38:13 -04:00
|
|
|
associated to one configuration group for a back end.
|
|
|
|
|
|
2015-03-02 07:37:37 +01:00
|
|
|
The following example shows five configured back ends::
|
2014-10-22 08:38:13 -04:00
|
|
|
|
|
|
|
|
[DEFAULT]
|
2015-02-24 13:49:36 -05:00
|
|
|
enabled_share_backends=backendEMC1,backendEMC2,backendGeneric1,backendGeneric2,backendNetApp
|
2014-10-22 08:38:13 -04:00
|
|
|
|
|
|
|
|
[backendEMC1]
|
2016-11-14 09:52:01 -05:00
|
|
|
share_driver=manila.share.drivers.dell_emc.driver.EMCShareDriver
|
2014-10-22 08:38:13 -04:00
|
|
|
share_backend_name=backendEMC1
|
|
|
|
|
emc_share_backend=vnx
|
|
|
|
|
emc_nas_server=1.1.1.1
|
|
|
|
|
emc_nas_password=password
|
|
|
|
|
emc_nas_login=user
|
|
|
|
|
emc_nas_server_container=server_2
|
|
|
|
|
emc_nas_pool_name="Pool 1"
|
|
|
|
|
|
|
|
|
|
[backendEMC2]
|
2016-11-14 09:52:01 -05:00
|
|
|
share_driver=manila.share.drivers.dell_emc.driver.EMCShareDriver
|
2014-10-22 08:38:13 -04:00
|
|
|
share_backend_name=backendEMC2
|
|
|
|
|
emc_share_backend=vnx
|
|
|
|
|
emc_nas_server=1.1.1.1
|
|
|
|
|
emc_nas_password=password
|
|
|
|
|
emc_nas_login=user
|
|
|
|
|
emc_nas_server_container=server_3
|
|
|
|
|
emc_nas_pool_name="Pool 2"
|
|
|
|
|
|
|
|
|
|
[backendGeneric1]
|
|
|
|
|
share_driver=manila.share.drivers.generic.GenericShareDriver
|
|
|
|
|
share_backend_name=one_name_for_two_backends
|
|
|
|
|
service_instance_user=ubuntu_user
|
|
|
|
|
service_instance_password=ubuntu_user_password
|
|
|
|
|
service_image_name=ubuntu_image_name
|
|
|
|
|
path_to_private_key=/home/foouser/.ssh/id_rsa
|
|
|
|
|
path_to_public_key=/home/foouser/.ssh/id_rsa.pub
|
|
|
|
|
|
|
|
|
|
[backendGeneric2]
|
|
|
|
|
share_driver=manila.share.drivers.generic.GenericShareDriver
|
|
|
|
|
share_backend_name=one_name_for_two_backends
|
|
|
|
|
service_instance_user=centos_user
|
|
|
|
|
service_instance_password=centos_user_password
|
|
|
|
|
service_image_name=centos_image_name
|
|
|
|
|
path_to_private_key=/home/baruser/.ssh/id_rsa
|
|
|
|
|
path_to_public_key=/home/baruser/.ssh/id_rsa.pub
|
|
|
|
|
|
|
|
|
|
[backendNetApp]
|
Manila NetApp cDOT driver refactoring
The Manila cDOT driver is a single file exceeding 1200 lines. It contains
multiple things (driver code, protocol helpers, ZAPI invocation code,
options) that should be split apart to allow for easier maintenance and
readability and add the potential for code sharing when we reintroduce
a 7-mode driver, add a single-SVM cDOT driver, etc.
We recently refactored NetApp's DOT Cinder drivers into a 4-layer
structure (interface, library, client, API) that separates concerns and
achieves the goals set forth above. This commit satisfies a plan to
do the same thing in Manila. The implementation steps are:
1. Update directory structure to match that of the Cinder NetApp drivers
2. Create driver interface shim
3. Move driver code to library (with base & C-mode classes, to allow for
7-mode code sharing later)
4. Move protocol helpers to separate files (already organized by base &
C-mode classes)
5. Split out ZAPI code to client layer (with base & C-mode classes, to
allow for 7-mode code sharing later)
6. Implement NetApp driver factory as in Cinder
7. Implement common NetApp options file as in Cinder
8. Implement cDOT API call optimizations
9. Update all unit tests as needed
Note that this patch appears to treble the total number of code lines.
This is due to the addition of many more unit tests plus a large amount
of fake controller API data to feed the API client tests.
Implements: blueprint netapp-manila-cdot-driver-refactoring
Closes-Bug: #1410317
Partial-Bug: #1396953
Closes-Bug: #1370965
Closes-Bug: #1418690
Closes-Bug: #1418696
Change-Id: I3fc0d09adf84a3708f110a89a7c8c760f4ce3588
2015-01-08 18:01:08 -05:00
|
|
|
share_driver = manila.share.drivers.netapp.common.NetAppDriver
|
|
|
|
|
driver_handles_share_servers = True
|
2014-10-22 08:38:13 -04:00
|
|
|
share_backend_name=backendNetApp
|
Manila NetApp cDOT driver refactoring
The Manila cDOT driver is a single file exceeding 1200 lines. It contains
multiple things (driver code, protocol helpers, ZAPI invocation code,
options) that should be split apart to allow for easier maintenance and
readability and add the potential for code sharing when we reintroduce
a 7-mode driver, add a single-SVM cDOT driver, etc.
We recently refactored NetApp's DOT Cinder drivers into a 4-layer
structure (interface, library, client, API) that separates concerns and
achieves the goals set forth above. This commit satisfies a plan to
do the same thing in Manila. The implementation steps are:
1. Update directory structure to match that of the Cinder NetApp drivers
2. Create driver interface shim
3. Move driver code to library (with base & C-mode classes, to allow for
7-mode code sharing later)
4. Move protocol helpers to separate files (already organized by base &
C-mode classes)
5. Split out ZAPI code to client layer (with base & C-mode classes, to
allow for 7-mode code sharing later)
6. Implement NetApp driver factory as in Cinder
7. Implement common NetApp options file as in Cinder
8. Implement cDOT API call optimizations
9. Update all unit tests as needed
Note that this patch appears to treble the total number of code lines.
This is due to the addition of many more unit tests plus a large amount
of fake controller API data to feed the API client tests.
Implements: blueprint netapp-manila-cdot-driver-refactoring
Closes-Bug: #1410317
Partial-Bug: #1396953
Closes-Bug: #1370965
Closes-Bug: #1418690
Closes-Bug: #1418696
Change-Id: I3fc0d09adf84a3708f110a89a7c8c760f4ce3588
2015-01-08 18:01:08 -05:00
|
|
|
netapp_login=user
|
|
|
|
|
netapp_password=password
|
|
|
|
|
netapp_server_hostname=1.1.1.1
|
2014-10-22 08:38:13 -04:00
|
|
|
netapp_root_volume_aggregate=aggr01
|