Manila minimum requirements and features¶
In order for a driver to be accepted into manila code base, there are certain minimum requirements and features that must be met, in order to ensure interoperability and standardized manila functionality among cloud providers.
At least one driver mode (DHSS true/false)¶
Driver modes determine if the driver is managing network resources (DHSS = true) in an automated way, in order to segregate tenants and private networks by making use of manila Share Networks, or if it is up to the administrator to manually configure all networks (DHSS = false) and be responsible for segregation, if that is desired. At least one driver mode must be supported. In DHSS = true mode, Share Server entities are used, so the driver must implement functions that setup and teardown such servers.
At least one file system sharing protocol¶
In order to serve shares as a shared file system service, the driver must support at least one file system sharing protocol, which can be a new protocol or one of the currently supported protocols. The current list of supported protocols is as follows:
NFS
CIFS
GlusterFS
HDFS
MapRFS
CephFS
Access rules¶
Access rules control how shares are accessible, by whom, and what the level of access is. Access rule operations include allowing access and denying access to a given share. The authentication type should be based on IP, User and/or Certificate. Drivers must support read-write and read-only access levels for each supported protocol, either through individual access rules or separate export locations.
Capabilities¶
In order for manila to function accordingly to the driver being used, the driver must provide a set of information to manila, known as capabilities. Share driver can use Share type extra-specs (scoped and un-scoped) to serve new shares. See Capabilities and Extra-Specs for more information. At a minimum your driver must report:
share_backend_name: a name for the backend;
driver_handles_share_servers: driver mode, whether this driver instance handles share servers, possible values are true or false;
vendor_name: driver vendor name;
driver_version: current driver instance version;
storage_protocol: list of shared file system protocols supported by this driver instance;
total_capacity_gb: total amount of storage space provided, in GB;
free_capacity_gb: amount of storage space available for use, in GB;
reserved_percentage: percentage of total storage space to be kept from being used.
Certain features, if supported by drivers, need to be reported in order to function correctly in manila, such as:
dedupe: whether the backend supports deduplication;
compression: whether the backend supports compressed shares;
thin_provisioning: whether the backend is overprovisioning shares;
pools: list of storage pools managed by this driver instance;
qos: whether the backend supports quality of service for shares;
replication_domain: string specifying a common group name for all backends that can replicate between each other;
replication_type: string specifying the type of replication supported by the driver. Can be one of (‘readable’, ‘writable’ or ‘dr’).
security_service_update_support: boolean specifying whether the driver supports updating or adding security services in an already deployed share server. It defaults to
False.
Below is an example of drivers with multiple pools. “my” is used as an example vendor prefix:
{
'driver_handles_share_servers': 'False', #\
'share_backend_name': 'My Backend', # backend level
'vendor_name': 'MY', # mandatory/fixed
'driver_version': '1.0', # stats & capabilities
'storage_protocol': 'NFS_CIFS', #/
#\
'my_capability_1': 'custom_val', # "my" optional vendor
'my_capability_2': True, # stats & capabilities
#/
'pools': [
{'pool_name':
'thin-dedupe-compression pool', #\
'total_capacity_gb': 500, # mandatory stats for
'free_capacity_gb': 230, # pools
'reserved_percentage': 0, #/
#\
'dedupe': True, # common capabilities
'compression': True, #
'snapshot_support': True, #
'create_share_from_snapshot_support': True,
'revert_to_snapshot_support': True,
'qos': True, # this backend supports QoS
'thin_provisioning': True, #
'max_over_subscription_ratio': 10, # (mandatory for thin)
'provisioned_capacity_gb': 270, # (mandatory for thin)
#
#
'replication_type': 'dr', # this backend supports
# replication_type 'dr'
#/
'my_dying_disks': 100, #\
'my_super_hero_1': 'Hulk', # "my" optional vendor
'my_super_hero_2': 'Spider-Man', # stats & capabilities
#/
#\
# can replicate to other
'replication_domain': 'asgard', # backends in
# replication_domain 'asgard'
#/
'ipv4_support': True,
'ipv6_support': True,
'security_service_update_support': False,
},
{'pool_name': 'thick pool',
'total_capacity_gb': 1024,
'free_capacity_gb': 1024,
'qos': False,
'snapshot_support': True,
'create_share_from_snapshot_support': False, # this pool does not
# allow creating
# shares from
# snapshots
'revert_to_snapshot_support': True,
'reserved_percentage': 0,
'dedupe': False,
'compression': False,
'thin_provisioning': False,
'replication_type': None,
'my_dying_disks': 200,
'my_super_hero_1': 'Batman',
'my_super_hero_2': 'Robin',
'ipv4_support': True,
'ipv6_support': True,
'security_service_update_support': False,
},
]
}
Continuous Integration systems¶
Every driver vendor must supply a CI system that tests its drivers continuously for each patch submitted to OpenStack gerrit. This allows for better QA and quicker response and notification for driver vendors when a patch submitted affects an existing driver. The CI system must run all applicable tempest tests, test all patches Zuul has posted +1 and post its test results.
Note
for more information please see http://docs.openstack.org/infra/system-config/third_party.html
Unit tests¶
All drivers submitted must be contemplated with unit tests covering at least 90% of the code, preferably 100% if possible. Unit tests must use mock framework and be located in-tree using a structure that mirrors the functional code, such as directory names and filenames. See template below:
manila/[tests/]path/to/brand/new/[test_]driver.py
Documentation¶
Drivers submitted must provide and maintain related documentation on openstack-manuals, containing instructions on how to properly install and configure. The intended audience for this manual is cloud operators and administrators. Also, driver maintainers must update the manila share features support mapping documentation found at https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html
Manila optional requirements and features since Mitaka¶
Additional to the minimum required features supported by manila, other optional features can be supported by drivers as they are already supported in manila and can be accessed through the API.
Snapshots¶
Share Snapshots allow for data respective to a particular point in time to be saved in order to be used later. In manila API, share snapshots taken can only be restored by creating new shares from them, thus the original share remains unaffected. If Snapshots are supported by drivers, they must be crash-consistent.
Manila experimental features since Mitaka¶
Some features are initially released as experimental and can be accessed by including specific additional HTTP Request headers. Those features are not recommended for production cloud environments while in experimental stage.
