The Manila share file system service provides a set of services for management of shared file systems in a multi-tenant cloud environment. The service resembles OpenStack block-based storage management from the OpenStack Block Storage service project. With the Shared File Systems service, you can create a remote file system, mount the file system on your instances, and then read and write data from your instances to and from your file system.
This charm configures a Manila backend using the NetApp Clustered Data ONTAP driver.
Manila NetApp Backend Source Charm
This charm provides NetApp Clustered Data ONTAP as a storage backend for Manila, OpenStack's shared filesystem service. It is written using the Juju operator framework.
The charm relies on the principal Manila charm, and is a subordinate to it. It
provides configuration data to the
manila-share service (which is provided by
the Manila charm with a role that includes 'share').
Prior to deploying this charm, a NetApp Data ONTAP cluster must be configured. It also needs L3 connectivity between the storage cluster and the Manila services. See the OpenStack driver documentation with details about the NetApp Clustered Data ONTAP driver, and known restrictions.
If multiple, different, NetApp backend configurations are required, then the
share-backend-name config option should be used to differentiate between the
Note: This subordinate charm requests that Manila principal charm configures
the Neutron conf file section, that the NetApp driver needs to allocate ports
for the storage vms when the
driver-handles-share-servers config is enabled.
The principal charm provides the main Manila service username/password to
this charm to enable it to provide this section.
driver-handles-share-servers is enabled, the driver will launch
storage vms (SMVs) within the NetApp Data ONTAP cluster. With this mode enabled,
Manila requires a share network to be defined.
A Manila share network is bound to a Neutron network and subnet. During a
share creation, the NetApp driver will allocate a port in the Neutron subnet
attached to the share network, and use that as the static IP for the SVM
spawned into NetApp Data ONTAP cluster. The only limitation to this mode is
that the Neutron network bound to the share network, needs to be
vlan, when using the NetApp driver.
With DHSS (driver handles share servers) enabled, the
CIFS share servers must
be configured with an external Active Directory (AD) for authentication. The AD
config info is provided to the Manila NetApp share servers via an
active_directory security service associated with
the share network.
Also, the NetApp driver requires credentials from an AD user with enough
privileges to register the new
CIFS share servers as computers in the AD
domain. These credentials are provided as part of the Manila security service
WARNING: The credentials for the required AD user are stored in plain text,
in the Manila database, as part of the associated security service. Tenant
users are able to see these when fetching information about the
active_directory security service. This is a potential security risk!
driver-handles-share-servers is disabled, an existing NetApp ONTAP
SVM must be pre-configured, and its name must be given as
the charm config.
Building the charm
To build the charm run the following command in the root of the repository:
$ tox -e build
The resultant built charm will be
One way to deploy Manila NetApp is to use a bundle overlay when deploying OpenStack via a bundle:
juju deploy ./base.yaml --overlay ./manila-netapp-overlay.yaml
The Manila NetApp bundle overlay might look like:
applications: manila-netapp: options: driver-handles-share-servers: False vserver-name: svm0 management-address: 10.1.1.10 admin-name: admin admin-password: my-secret-admin-password
Please report bugs on Launchpad.
For general charm questions refer to the OpenStack Charm Guide.
- (string) Administrative user account name used to access the storage system.
- (string) Password for the administrative user account specified in the 'admin-name' option.
- (boolean) Whether the Manila driver should manage the Vservers within the NetApp ONTAP cluster.
- (string) Comma-separated list of NFS protocol versions that will be enabled on the Vservers from the NetApp ONTAP cluster. The supported versions are: * nfs3 * nfs4.0 * nfs4.1 This option only applies when the option 'driver-handles-share-servers' is set to True.
- (string) The management address (IP or hostname) for the NetApp ONTAP cluster.
- (string) Name of aggregate to create Vserver root volumes on. This option only applies when the option 'driver-handles-share-servers' is set to True.
- (string) The name given to the backend. This is used to generate the backend configuration section. If two different configurations of the same backend type are needed, then this config option can be used to separate them in the backend configuration.
- (string) The name of the Vserver already configured within the NetApp ONTAP cluster. This option is used only when 'driver-handles-share-servers' is set to False.