Manila Administrators create share types with extra-specs to allow users to request a type of share to create. The Administrator chooses a name for the share type and decides how to communicate the significance of the different share types in terms that the users should understand or need to know. By design, most of the details of a share type (the extra- specs) are not exposed to users – only Administrators.
There are 3 types of extra-specs: required, scoped, and un-scoped.
Manila requires the driver_handles_share_servers extra-spec.
Scoped extra-specs use a prefix followed by a colon to define a namespace for scoping the extra-spec. A prefix could be a vendor name or acronym and is a hint that this extra-spec key/value only applies to that vendor’s driver. Scoped extra-specs are not used by the scheduler to determine where a share is created (except for the special capabilities prefix). It is up to each driver implementation to determine how to use scoped extra-specs and to document them.
The prefix “capabilities” is a special prefix to indicate extra-specs that are treated like un-scoped extra-specs. In the CapabilitiesFilter the “capabilities:” is stripped from the key and then the extra-spec key and value are used as an un-scoped extra-spec.
Un-scoped extra-specs have a key that either starts with “capabilities:” or does not contain a colon. When the CapabilitiesFilter is enabled (it is enabled by default), the scheduler will only create a share on a backend that reports capabilities that match the share type’s un-scoped extra-spec keys.
The CapabilitiesFilter uses the following for matching operators:
No operator This defaults to doing a python ==. Additionally it will match boolean values.
<=, >=, ==, !=
This does a float conversion and then uses the python operators as expected.
<in>
This either chooses a host that has partially matching string in the capability or chooses a host if it matches any value in a list. For example, if “<in> sse4” is used, it will match a host that reports capability of “sse4_1” or “sse4_2”.
<or>
This chooses a host that has one of the items specified. If the first word in the string is <or>, another <or> and value pair can be concatenated. Examples are “<or> 3”, “<or> 3 <or> 5”, and “<or> 1 <or> 3 <or> 7”. This is for string values only.
<is>
This chooses a host that matches a boolean capability. An example extra-spec value would be “<is> True”.
=
This does a float conversion and chooses a host that has equal to or greater than the resource specified. This operator behaves this way for historical reasons.
s==, s!=, s>=, s>, s<=, s<
The “s” indicates it is a string comparison. These choose a host that satisfies the comparison of strings in capability and specification. For example, if “capabilities:replication_type s== dr”, a host that reports replication_type of “dr” will be chosen.
For vendor-specific capabilities (which need to be visible to the CapabilityFilter), it is recommended to use the vendor prefix followed by an underscore. This is not a strict requirement, but will provide a consistent look along-side the scoped extra-specs and will be a clear indicator of vendor capabilities vs. common capabilities.
For capabilities that apply to multiple backends a common capability can be created.
Drivers report capabilities as part of the updated stats (e.g. capacity) for their backend/pools. This is how a backend/pool advertizes its ability to provide a share that matches the capabilities requested in the share type extra-specs.
Developers should update their drivers to include all backend and pool capacities and capabilities in the share stats it reports to scheduler. Below is an example having 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, #
'qos': True, # this backend supports QoS
'thin_provisioning': True, #
'max_over_subscription_ratio': 10, # (mandatory for thin)
'provisioned_capacity_gb': 270, # (mandatory for thin)
#/
'my_dying_disks': 100, #\
'my_super_hero_1': 'Hulk', # "my" optional vendor
'my_super_hero_2': 'Spider-Man' # stats & capabilities
#/
},
{'pool_name': 'thick pool',
'total_capacity_gb': 1024,
'free_capacity_gb': 1024,
'qos': False,
'reserved_percentage': 0,
'dedupe': False,
'compression': False,
'thin_provisioning': False,
'my_dying_disks': 200,
'my_super_hero_1': 'Batman',
'my_super_hero_2': 'Robin',
},
]
}