Support IPv6 access in manila¶
Currently ip access rule type only supports IPv4. A valid format is xxx.xxx.xxx.xxx or xxx.xxx.xxx.xxx/xx. This is not enough when users want to enable IPv6 in manila. The most affected areas are API (access rules) and the drivers (access rules & export locations).
End users with IPv6 interfaces also want to access their shares, and manila currently only supports IPv4 protocol when access is IP-based.
Support IPv6 in access rule
As agreed by the manila community in IRC meeting (topic IPv6) , manila can address this requirement by adding the IPv6 format validation for ip access rule type. Change the validation approach from our own function (_validate_ip_range) to a standard module ‘ipaddress’ (both IPv4 and IPv6 are supported).
With the ipaddress module, the IPv6 formats below are all considered acceptable:
2001:0DB8:02de:0000:0000:0000:0000:0e13 #uncompressed 2001:DB8:2de:0:0:0:0:0e13 #leading zeros removed 2001:DB8:2de::0e13 #consecutive sections of zeroes omitted 2001:dB8:2De::0E13 #mixed case 2001:dB8::/32 #network range
and manila will convert all of these into lower and compressed format, which means the result of first example will be like (it’s also a canonical format which is recommended in RFC5952 ):
Support IPv6 in network plugins
The standalone and neutron network plugins (nova network plugins are ignored as they are being deprecated) will have to be modified to support IPv6.
Network plugins will add new boolean configuration options ‘network_plugin _ipv4_enabled’ and ‘network_plugin_ipv6_enabled’ to indicate its enabled ip versions. The default values are ‘True’ and ‘False’ respectively. We will ultimately support both IPv4 and IPv6 enabled for single network plugin, but for this phase, restricted to the current manila network plugin architecture, only one option should be configured True (either IPv4 or IPv6) in Ocata. We will also deprecate the ‘standalone_network_plugin_ip _version’ which will be equivalent to ‘network_plugin_ipv6_enabled=True’ and ‘network_plugin_ipv4_enabled=False’, or on the contrary.
Network plugins should be updated to allocate network resource based on their ip version’s configuration (both for user network and admin network). For example, the neutron network plugins will only allocate IPv6 ports if ‘network_plugin_ipv6_enabled = True’. If no suitable resource is found with the configured or specified network resource the allocation process would fail with exception.
Support IPv6 in drivers
As the export location support’s status varies in different drivers, manila will introduce two extra_specs (and driver capabilities) ‘ipv4_support’, ‘ipv6_support’ to make backends and users easy to support and configure.
Add new optional boolean extra_specs ‘ipv4_support’, ‘ipv6_support’ for share type that indicates the required ip version (Omitting either extra_spec means “don’t care” about a match for that capability).
Drivers have to report the capabilities with the ip version which they can support, the capability is reported in the same format with extra_specs. There are two cases that driver should consider: - DHSS=false, the driver should report IPv4 is True only if it is actually configured with IPv4 export locations, and IPv6 is True only if it is actually configured to support IPv6 export locations. - DHSS=true, the driver should report IPv4 is True only if both driver and the configured network plugins (both user and admin) have the IPv4 capability, so does the IPv6.
The manila scheduler will choose the correct backend with capability filter when ip version extra_specs are involved.
Driver must return export locations according to its IP version capabilities, and only host addresses are allowed in export locations, not hostnames.
Data model impact¶
REST API impact¶
The API microversion will have to be bumped for this.
The IPv6 address and IPv6 network are supported in allow_access action.
Drivers will be updated so that existing drivers that use IPv4 addresses will report ipv4_support=True. When drivers support both IPv4 and IPv6, they need report their support versions based on their capabilities and configuration of the storage backend. Also the following functions might need to be changed:
Also, drivers must export locations as addresses rather than as host names since addresses are specifically IPv4 or IPv6 whereas host names could resolve to either an IPv4 or an IPv6 address at any particular time.
Other end user impact¶
python-manilaclient will be changed to reflect the validation approach changes for ip access type.
The access-allow command with IPv6 supported will be like:
manila access-allow test_share ip "AD80:0:0:0:ABAA:0:C2:2"
manila-ui will have corresponding UI changes to deal with the valid value for ip access rule type after python-manilaclient implementation.
Other deployer impact¶
Deployers must ensure their IP version preferences are reflected on the storage backends, such that data interfaces have IPv4 and IPv6 addresses as desired.
Changes to the driver interface are noted above. Third party backends will implement these changes and report their IPv6’s ability if they want to enable IPv6 in their drivers (the support matrix can be found here ).
Implement core feature
Report capability ipv4_support=True for existing IPv4 drivers
Implement IPv6 in network plugins.
Implement IPv6 ACL in generic, huawei and dummy drivers
Implement tempest tests
Implement Scenario tests
Implement manila-ui support
Implement python-manilaclient support
Update manila API documentation
Update manila guide documentation on IPv6
Update user guide
Update manila API documentation
Update manila developer documentation on IPv6
 http://eavesdrop.openstack.org/meetings/manila/2016/manila.2016-08-25-15.00.log.html  https://tools.ietf.org/html/rfc5952#section-4  http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html