Python2 is no longer supported, so in this patch
set we remove the usage of the six (py2 and py3
compatibility library) in favor of py3 syntax.
Change-Id: I3ddfad568a1b578bee23a6d1a96de9551e336bb4
The NetApp driver has been working with FlexVol ONTAP volumes.
The driver does not support scaling FlexVol volumes higher than
100 TiB, which was a theoretical limit for the large namespace that
these containers were meant to handle. ONTAP's Flexgroup volumes
eliminate such limitations. So, added the support for provisioning
share as FlexGroup in the NetApp driver.
The FlexGroup provision is enabled by new option
`netapp_enable_flexgroup`, which will make the driver report a single
pool represeting all aggregates. The selection on which aggregates the
FlexGroup share will reside is up to ONTAP. If the administrator desires
to control that selection through Manila scheduler, it must inform the set
of aggregates that formss FlexGroup pool in the new option
`netapp_flexgroup_pool`.
Each NetApp pool will report now the capability: `netapp_flexgroup`
informing which type the pool is.
The following operations are allowed with FlexGroup shares (DHSS
True/False and NFS/CIFS):
- Create/Delete share;
- Shrink/Extend share;
- Create/Delete snapshot;
- Revert to snapshot;
- Manage/Unmanage snapshots;
- Create from snapshot;
- Replication[1]
- Manage/Unmanage shares;
The backend with one FlexGroup pool configured will drop the consistent
snapshot support for all pools.
The driver FlexGroup support requires ONTAP version 9.8 or greater.
[1] FlexGroup is limited to one single replica for ONTAP version
lower than 9.9.1.
DocImpact
Depends-On: If525e97a5d456d6ddebb4bf9bc8ff6190c95a555
Depends-On: I646f782c3e2be5ac799254f08a248a22cb9e0358
Implements: bp netapp-flexgroup-support
Change-Id: I4f68a9bb33be85f9a22e0be4ccf673647e713459
Signed-off-by: Felipe Rodrigues <felipefuty01@gmail.com>
Implement the `readable` replication type for the NetApp driver.
The driver will keep having support for the `dr` type as well, being
the driver replication type a list containing them.
The replicas for readable style are mounted, created the export and
applied the QoS. When promoting, the original active replica does
not need to be unmounted. The user just loses the write access.
The update access interface is now applying rules for non active
replicas that are readable.
Implements: bp netapp-readable-replica
Change-Id: Icc74eaecc75c3064715f91bebb994e93c0053663
Signed-off-by: Felipe Rodrigues <felipefuty01@gmail.com>
- Fixes the zapi calls for setting up a kerberos, which have
changed since ONTAP 8.3.
- Fixes kerberos configuration cleanup when deleting a
share server.
- Fixes access rules authentication methods for NFS when a
share server is configured for Kerberos.
Change-Id: I60b4f92979045b1fdb90ad8df4f65c1dfe463ae8
Closes-Bug: #1901189
Closes-Bug: #1904746
Closes-Bug: #1907669
Co-Authored-By: Felipe Rodrigues <felipefuty01@gmail.com>
Signed-off-by: Douglas Viroel <viroel@gmail.com>
This change fixes the NetApp promote back issue when using CIFS
protocol. When promoting a replica, the NetApp ONTAP driver
attempts to create a new CIFS share entity (an access point as
defined in [1]) for the new active replica. This behavior
causes a failure since the storage identifies that a current
backend CIFS share with the same name exists, considering
that the reffered replica was once the active one.
This issue is addressed by removing the related CIFS share
entity when the replica gets promoted.
[1] https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-1898D717-A510-4B3D-B2E3-CCDDD5BD0089.html
Closes-Bug: #1879368
Change-Id: Id9bdd5df0ff05ea08881dd2c83397f0a367d9945
This patch adds support for share server migration between NetApp
ONTAP drivers. This operation is now supported for migrating a share
server and all its resources between two different clusters.
Share server migration relies on ONTAP features available only in
versions equal and greater than ``9.4``. Also, in order to have share
server migration working across ONTAP clusters, they must be peered in
advance.
At this moment, share server migration doesn't support migrate a share
server without disrupting the access to shares, since the export locations
are updated at the migration complete phase.
The driver doesn't support changing security services while changing the
destination share network. This functionality can be added in the future.
Co-Authored-By: Andre Beltrami <debeltrami@gmail.com>
Implements: bp netapp-share-server-migration
Depends-On: Ic0751027d2c3f1ef7ab0f7836baff3070a230cfd
Change-Id: Idfac890c034cf8cbb65abf685ab6cab5ef13a4b1
Signed-off-by: Douglas Viroel <viroel@gmail.com>
This patch implements the functionality of managing and
unmanaging of share servers to the NetApp driver,
allowing for shares and snapshots to be managed
and unmanaged in DHSS=True driver mode.
Implements: bp netapp-driver-manage-unmanage-with-share-servers
Change-Id: I6051cf038dcf9f175e0610fff0adf360230dc23c
Depends-On: I452c2a99b186f53d737cb7fbd7eabfcfd9b249d6
Escape IPv6 exports correctly and setup the default export
policy to allow both IPv4 and IPv6.
Partially implements: bp netapp-ontap-ipv6-support
Change-Id: I84437b140e2a9561cc4092683209800101f45815
Some of the available checks are disabled by default, like:
[H106] Don't put vim configuration in source files
[H203] Use assertIs(Not)None to check for None
[H904] Use ',' instead of '%', String interpolation should be
delayed to be handled by the logging code, rather than
being done at the point of the logging call.
Change-Id: Ie985fcf78997a86d41e40eacbb4a5ace8592a348
Add migration support in the cDOT driver.
Change-Id: I72e045b1c978b752f38cc3018cb2a7084e3f3e36
Implements: blueprint netapp-cdot-driver-optimized-migration
Since the export location metadata feature has merged in Manila core,
we can support it in the NetApp drivers. The initial need is to
report which paths are preferred.
Implements: blueprint netapp-cdot-export-location-metadata
Depends-On: Ibb88c64ddd899c09cd148f398e21ac613be9f15b
Change-Id: I77e3a6464c6da59cfafa34bd23c23740efbcf7c1
This commit replaces the allow_access and deny_access methods
in the NetApp cDOT drivers with the new update_access method. Due
to how cDOT works, the driver always uses the full update path
instead of adding or removing access rules one at a time.
The rules are added in an order that guarantees no transient
interruptions occur, and the IP addresses for NFS are sorted such
that single addresses and smaller subnets take precedence over
larger networks.
Change-Id: I040690895ca1a60f5964a6d01a799b613f7f6a30
Implements: blueprint netapp-cdot-update-access
Read-only shares are now a required Manila feature. The cDOT driver
supports read-only access for NFS shares but not CIFS. This commit
adds CIFS read-only support.
Closes-Bug: #1513509
Change-Id: Ib7367d80c263331341ca136b61fa8185e894db3b
This commit adds support to the cDOT driver for the driver methods
manage_existing and unmanage. The logic follows three sections:
1. Locate the resource to be managed, which is specified as the
cDOT flexvol name in the export_path argument.
2. Ensure the flexvol to be brought under Manila management is
of the appropriate type, the extra specs from the share type are
valid and match the specified pool, and the flexvol has no LUNs
or other flexvols mounted underneath it.
3. Rename the flexvol using normal Manila naming conventions,
remount it on a new path matching the new name, update it to
conform to all relevant qualified extra specs, and remove any
existing export rules.
Implements blueprint netapp-cdot-driver-manage-unmanage-share
Change-Id: Ib6832baf24585791bf7ec292e5c6cdeb83fe280d
When clustered Data ONTAP clones a flexvol, the clone gets the
NFS export policy of its parent. Manila expects the clone to be
independent of its parent, so it should be given its own export
policy. This isn't happening in the Kilo cDOT driver.
Change-Id: I5067fc5729bec62de19d1aeaed7ed60d2224e498
Closes-Bug: #1446369
The nfs-exportfs-* APIs that the NetApp cDOT driver currently uses
for NFS export management are 7-mode APIs which were left in for
backwards compatibility. It's not the recommended/supported way
to do NFS export management. We need to modify the driver to use
the supported set of export-policy-* and export-rule-* APIs.
Closes-Bug: #1370761
Closes-Bug: #1437509
Change-Id: I91347d27ba69d4a20fe73ce7e75f58c9818ea6d8
Manila has the ability for shares to report multiple export locations.
This is an important capability for drivers that manage storage
backends that export shares on multiple network interfaces. This
commit adds this capability to the cDOT driver. This commit also
updates the cDOT driver to use backslashes in CIFS export paths.
Change-Id: I772caaad2871a072bb5bc4a505678d9fbf0c579c
Closes-Bug: #1429246
When using manila with a cDOT backend, the 'manila create' command
creates an export-policy for every newly created NFS share and adds
a policy rule with "localhost". This is not necessary.
Change-Id: If4b54255328ed7384a195609d7e4e99c79d10638
Closes-Bug: #1427791
The extant Manila driver for cDOT supports multi-svm mode only
(i.e. driver_handles_share_servers = True). This commit adds
a single-svm cDOT driver (driver_handles_share_servers = False)
for simpler operation without network plug-ins. To work in this
mode the storage admin must pre-create a vserver with the desired
LIFs and protocols configured, and specify the vserver in
the config variable 'netapp_vserver'.
To configure this driver, use a config like the following:
[cmode]
share_driver = manila.share.drivers.netapp.common.NetAppDriver
driver_handles_share_servers = False
netapp_storage_family = ontap_cluster
netapp_server_hostname=192.168.228.42
netapp_login=admin
netapp_password=cluster3
netapp_server_port=443
netapp_transport_type=https
netapp_aggregate_name_search_pattern=manila
netapp_vserver = manila_svm
Implements blueprint netapp-cdot-driver-without-handling-share-servers
Change-Id: I0cfafe3d64a9a9b52f1eca9f28a0e937b3b84f44
Like Cinder, Manila has a scheduler that operates (among other things)
on extra spec values in share types to determine which backend should
receive a new share. In Kilo, Manila will adopt the pools feature from
Cinder, such that the scheduler may choose from more than one storage
destination per backend. This commit adds a couple of per-pool
attributes to the share stats reported by the cDOT driver to the scheduler,
including aggregate disk type and RAID type.
Implements blueprint cdot-storage-service-catalog
Change-Id: Ice616d4189832d0e4b1a0fdfdd31b82b8c0a831d
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
haixin