Merge "Add spec for enable IPv6 in manila"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
6fd17c1ceb
|
|
@ -0,0 +1,240 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=============================
|
||||
Support IPv6 access in manila
|
||||
=============================
|
||||
|
||||
https://blueprints.launchpad.net/manila/+spec/support-ipv6-access
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
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).
|
||||
|
||||
Use cases
|
||||
=========
|
||||
|
||||
End users with IPv6 interfaces also want to access their shares, and manila
|
||||
currently only supports IPv4 protocol when access is IP-based.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* Support IPv6 in access rule
|
||||
|
||||
As agreed by the manila community in IRC meeting (topic IPv6) [1], 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 [2])::
|
||||
|
||||
2001:db8:2de::e13
|
||||
|
||||
* 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.
|
||||
|
||||
1. 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.
|
||||
|
||||
2. 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.
|
||||
|
||||
1. 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).
|
||||
|
||||
2. 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.
|
||||
3. The manila scheduler will choose the correct backend with capability
|
||||
filter when ip version extra_specs are involved.
|
||||
4. Driver must return export locations according to its IP version
|
||||
capabilities, and only host addresses are allowed in export locations,
|
||||
not hostnames.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
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.
|
||||
|
||||
Driver impact
|
||||
-------------
|
||||
|
||||
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:
|
||||
|
||||
* _update_share_stats
|
||||
* create_share
|
||||
* delete_share
|
||||
* create_share_from_snapshot
|
||||
* update_access
|
||||
* setup_server
|
||||
* manage_existing
|
||||
* create_replica
|
||||
* promote_replica
|
||||
* migration_start
|
||||
* migration_complete
|
||||
* create_consistency_group
|
||||
* create_consistency_group_from_cgsnapshot
|
||||
|
||||
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.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Performance impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
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.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
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 [3]).
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* zhongjun(jun.zhongjun2@gmail.com)
|
||||
* TommyLike(tommylikehu@gmail.com)
|
||||
* zengyingzhe(zengyingzhe@huawei.com)
|
||||
|
||||
Work items
|
||||
----------
|
||||
|
||||
* 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
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* Unit test
|
||||
* Functional test
|
||||
* Tempest test
|
||||
|
||||
Documentation impact
|
||||
====================
|
||||
|
||||
* Update user guide
|
||||
* Update manila API documentation
|
||||
* Update manila developer documentation on IPv6
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] http://eavesdrop.openstack.org/meetings/manila/2016/manila.2016-08-25-15.00.log.html
|
||||
[2] https://tools.ietf.org/html/rfc5952#section-4
|
||||
[3] http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html
|
||||
Loading…
Reference in New Issue