A Manila backend is the configuration object that represents a single provider of resource pools upon which provisioning requests for shared file systems may be fulfilled. A Manila backend communicates with the storage system through a Manila driver. Manila supports multiple backends to be configured and managed simultaneously (even with the same Manila driver).
Note
A single Manila backend may be defined in the [DEFAULT] stanza
of manila.conf; however, NetApp recommends that the
enabled_share_backends configuration option be set to a
comma-separated list of backend names, and each backend name have
its own configuration stanza with the same name as listed in the
enabled_share_backends option. Refer to the section called
“Theory of Operation: Manila.conf” for an example of the use of this option.
With the Kilo release of OpenStack, Manila has introduced the concept of “storage pools”. The backend storage may present one or more logical storage resource pools from which Manila will select as a storage location when provisioning shares. In releases prior to Kilo, NetApp’s Manila drivers contained some logic that determined which aggregate a Manila share would be placed into; with the introduction of pools, all scheduling logic is performed completely within the Manila scheduler.
Important
For NetApp’s Manila drivers, a Manila storage pool is an aggregate defined within ONTAP.
A Manila driver is a particular implementation of a Manila backend that maps the abstract APIs and primitives of Manila to appropriate constructs within the particular storage solution underpinning the Manila backend.
Caution
The use of the term “driver” often creates confusion given common understanding of the behavior of “device drivers” in operating systems. The term can connote software that provides a data I/O path. In the case of Manila driver implementations, the software provides provisioning and other manipulation of storage devices but does not lay in the path of data I/O. For this reason, the term “driver” is often used interchangeably with the alternative (and perhaps more appropriate) term “provider”.
A Manila share type is an abstract collection of criteria used to
characterize Manila shares. They are most commonly used to create a
hierarchy of functional capabilities that represent a tiered level of
storage services; for example, a cloud administrator might define a
premium share type that indicates a greater level of performance
than a basic share type, which would represent a best-effort level
of performance.
The collection of criteria is specified as a list of key/value pairs, which are inspected by the Manila scheduler when determining which resource pools are able to fulfill a provisioning request. Individual Manila drivers (and subsequently Manila backends) may advertise arbitrary key/value pairs (also referred to as capabilities) to the Manila scheduler for each pool, which are then compared against share type definitions when determining which pool will fulfill a provisioning request.
An extra spec is a key/value pair, expressed in the style of
key=value. Extra specs are associated with Manila share types, so
that when users request shares of a particular share type, the shares
are created on pools within storage backends that meet the specified
criteria.
Note
The list of default capabilities that may be reported by a Manila driver and included in a share type definition include:
share_backend_name: The name of the backend as defined in
manila.confvendor_name: The name of the vendor who has implemented the
driver (e.g. NetApp)driver_version: The version of the driver (e.g. 1.0)storage_protocol: The protocol used by the backend to export
block storage to clients (e.g. NFS_CIFS)For a table of NetApp supported extra specs, refer to Table 6.10, “NetApp supported Extra Specs for use with Manila Share Types”.
A Manila snapshot is a point-in-time, read-only copy of a Manila share. Snapshots can be created from an existing Manila share that is operational regardless of whether a client has mounted the file system. A Manila snapshot can serve as the content source for a new Manila share when the Manila share is created with the create from snapshot option specified.
Important
In the Mitaka and Newton release of OpenStack, snapshot support is
enabled by default for a newly created share type. Starting with the
Ocata release, the snapshot_support extra spec must be set to
True in order to allow snapshots for a share type. If the
‘snapshot_support’ extra_spec is omitted or if it is set to False,
users would not be able to create snapshots on shares of this share
type.
Other snapshot-related extra specs in the Ocata release (and later) include:
create_share_from_snapshot_support: Allow the creation of a
new share from a snapshotrevert_to_snapshot_support: Allow a share to be reverted to
the most recent snapshotIf an extra-spec is left unset, it will default to ‘False’, but a
newly created share may or may not end up on a backend with the
associated capability. Set the extra spec explicitly to False,
if you would like your shares to be created only on backends that do
not support the associated capabilities. For a table of NetApp
supported extra specs, refer to Table 6.10,
“NetApp supported Extra Specs for use with Manila Share Types”.
Security services are the concept in Manila that allow Finer-grained client access rules to be declared for authentication or authorization to access share content. External services including LDAP, Active Directory, Kerberos can be declared as resources that should be consulted when making an access decision to a particular share. Shares can be associated to multiple security services.
Important
When creating a CIFS share, the user will need to create a Security Service with any of the 3 options (LDAP, Active Directory or Kerberos) and then add this Security Service to the already created Share Network.
This document is licensed under Apache 2.0 license.