Remove volume driver specs and move Liberty specs
New volume drivers don't need specs. Also some things need to be moved over to Liberty that weren't done in Kilo. Change-Id: Ic44a35c01278fdc2fbe0a1614c32914542b01925
This commit is contained in:
Mike Perez
parent
3614b71588
commit
6f2a2b1053
@ -1,182 +0,0 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
======================================
|
||||
NetApp Data ONTAP FibreChannel drivers
|
||||
======================================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/add-fibre-channel-support-to-
|
||||
netapp-drivers
|
||||
|
||||
NetApp's Cinder volume drivers for Data ONTAP support iSCSI, and we are adding
|
||||
FibreChannel support as well.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Cinder volume drivers must extend the protocol-specific subclass of
|
||||
VolumeDriver (i.e. ISCSIDriver or FibreChannelDriver). The inheritance model
|
||||
employed by the NetApp iSCSI drivers is not conducive to adding FibreChannel
|
||||
support to their extant iSCSI capability.
|
||||
|
||||
Other vendors have moved common, protocol-agnostic driver code into library
|
||||
modules and called those from the actual driver modules, which then become
|
||||
very thin indirection layers. NetApp will take this approach as well.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
We will make the following changes:
|
||||
|
||||
* Move all iSCSI Data ONTAP driver code into library modules (base class plus
|
||||
subclasses for 7-mode and cluster-mode specializations).
|
||||
|
||||
* Convert the driver modules for iSCSI (7-mode and cluster-mode) into thin
|
||||
indirection layers.
|
||||
|
||||
* Add corresponding FibreChannel driver modules that call (mostly) the same
|
||||
logic in the library modules.
|
||||
|
||||
* Enhance the libraries' handling of igroups and initiators to be multi-
|
||||
initiator-aware, since FC HBAs typically report multiple host-side WWPNs to
|
||||
Nova/Cinder.
|
||||
|
||||
* Enhance the library modules to handle FC-specific attach/detach operations
|
||||
in the same way as other FC drivers. We will take full advantage of the
|
||||
Zone Manager code in Cinder.
|
||||
|
||||
* Enhance our unit tests to cover all the proposed changes, and continue the
|
||||
multi-release process of moving NetApp's Cinder unit tests into the correct
|
||||
directory structure.
|
||||
|
||||
The refactoring needed in the iSCSI drivers to pave the way for FC drivers
|
||||
will be submitted first, followed by a separate submission to add the FC
|
||||
drivers themselves.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
In addition to the library approach, we also considered building our drivers
|
||||
using Python mixins, which would eliminate the indirection layer in the driver
|
||||
modules. The problem with mixins is that IDEs cannot follow references, and
|
||||
the mixins cannot be standalone modules since they need common data such as
|
||||
Cinder configuration objects. We prototyped both approaches, but the library
|
||||
solution is much more convenient to work with.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
One new NetApp-specific config flag is required: netapp_partner_backend_name
|
||||
|
||||
NetApp Data ONTAP (7-mode) storage controllers typically operate in HA pairs,
|
||||
and in a FibreChannel (FC) environment each controller presents LUNs from its
|
||||
partner into the FC fabric(s). So the driver must be able to read the FC
|
||||
port info and LUN map info from not only the controller owning a LUN but also
|
||||
from its HA partner. The added flag identifies the config file stanza for the
|
||||
HA partner (which is always its own Cinder backend). This approach is much
|
||||
cleaner than duplicating all the partner connection details in each backend
|
||||
stanza.
|
||||
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Clinton Knight (cknight)
|
||||
|
||||
Other contributors:
|
||||
Rushil Chugh (rushil)
|
||||
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Set up FC dev/test environment.
|
||||
|
||||
* Refactor drivers to move block storage code into reusable libraries.
|
||||
|
||||
* Create FC driver modules for Data ONTAP (7-mode & cluster-mode).
|
||||
|
||||
* Update & extend unit tests accordingly.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* The refactoring to prepare for FC drivers was captured in a separate
|
||||
blueprint: https://blueprints.launchpad.net/cinder/+spec/netapp-cinder-
|
||||
driver-refactoring-phase-1
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Running our existing tempest tests in the FC dev/test environment is the
|
||||
initial step to know the FC-specific changes in the driver libraries are
|
||||
working. Regression tests in iSCSI environments will ensure nothing was
|
||||
broken.
|
||||
|
||||
We are also building a CI system, which will be extended during Kilo to
|
||||
include running tempest in an FC environment.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
What is the impact on the docs team of this change? Some changes might require
|
||||
donating resources to the docs team to have the documentation updated. Don't
|
||||
repeat details discussed above, but please reference them here.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* The FC implementation described above was informed by pre-existing FC
|
||||
drivers from other vendors, most notably the HP/3PAR one. A conversation
|
||||
with Walter Boring was very helpful.
|
||||
|
||||
@ -1,185 +0,0 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==============================================
|
||||
Cinder volume driver for Huawei Dsware
|
||||
==============================================
|
||||
|
||||
Include the URL of your launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/huawei-dsware-driver
|
||||
|
||||
This proposal is to add Huawei Dsware driver to cinder.
|
||||
|
||||
Huawei Dsware is a virtual SAN product, virtualizes homogeneous local
|
||||
disk device from mutiple hosts to provide virtual block device,
|
||||
while providing advanced features such as snapshot, clone,thin provision,
|
||||
cache and so on.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently, user can't access Huawei Dsware by Openstack Cinder.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
We will add a new Cinder driver that uses socket API to interact with Huawei
|
||||
Dsware storage. Dsware data panel using private Key-Value protocal,
|
||||
so we also add a new connector to realize attach/detach volume.
|
||||
|
||||
The following diagram shows the command and data paths.
|
||||
|
||||
::
|
||||
|
||||
+------------------+
|
||||
| |
|
||||
| Cinder + |
|
||||
| Cinder Volume |
|
||||
| |
|
||||
| |
|
||||
+------------------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+---------------+-------+ +----+------------------+
|
||||
| | | |
|
||||
| | | |
|
||||
| Dsware | | Dsware Driver |
|
||||
| connector | | |
|
||||
| | | |
|
||||
+-----------------------+ +-----------------------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
CLI Socket API
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+--+-----------+---+
|
||||
| |
|
||||
| |
|
||||
| Dsware |
|
||||
| storage |
|
||||
| |
|
||||
+------------------+
|
||||
|
||||
|
||||
|
||||
Add new driver in /cinder/volume/drivers path, and realize cinder driver
|
||||
minimum features:
|
||||
* Volume Create/Delete
|
||||
* Volume Attach/Detach
|
||||
* Snapshot Create/Delete
|
||||
* Create Volume from Snapshot
|
||||
* Get Volume Stats
|
||||
* Copy Image to Volume
|
||||
* Copy Volume to Image
|
||||
* Clone Volume
|
||||
* Extend Volume
|
||||
|
||||
Add a new connector which can be shared with Huawei SDShypervisor in
|
||||
cinder/brick/initiator path, and realize abstract connector methods:
|
||||
* connect_volume
|
||||
* disconnect_volume
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
User will be able to use Huawei Dsware with Cinder.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
zhangni <zhangni@huawei.com>
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Realize Cinder driver minimum features using socket API.
|
||||
Realize new connector using CLI.
|
||||
Add CI unit test plugins for Huawei Dsware cinder driver and
|
||||
connector.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Because Dsware data panel using private Key-Value protocal, we will create a
|
||||
new libvirt volume driver in Nova to realize attach/detach volume to
|
||||
instance.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Continuous integration will be done for Huawei Dsware Driver.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The CinderSupportMatrix table should be updated to add Huawei Dsware.
|
||||
https://wiki.openstack.org/wiki/CinderSupportMatrix
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
@ -1,174 +0,0 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Cinder volume driver for X-IO ISE storage
|
||||
==========================================
|
||||
|
||||
Include the URL of your launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/xio-iscsi-fc-volume-driver
|
||||
|
||||
Add Cinder volume driver for X-IO ISE storage products. The driver will
|
||||
implement all APIs required to support both FC and iSCSI protocols.
|
||||
It communicates with the ISE storage unit using REST.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently no volume driver for X-IO ISE storage available in any release
|
||||
branch.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The new driver will add support for ISE storage products as backend storage
|
||||
in Cinder.
|
||||
The driver supports the following APIs:
|
||||
* Volume Create/Delete
|
||||
* Volume Attach/Detach
|
||||
* Snapshot Create/Delete
|
||||
* Create Volume from Snapshot
|
||||
* Get Volume Stats
|
||||
* Copy Image to Volume
|
||||
* Copy Volume to Image
|
||||
* Clone Volume
|
||||
* Extend Volume
|
||||
|
||||
Driver will be implemented using three classes in separate files.
|
||||
|
||||
* class XIOISEDriver
|
||||
Main class common to FC and ISCSI driver classes.
|
||||
|
||||
* class XIOISCSIDriver
|
||||
Driver specific for ISCSI protocol.
|
||||
|
||||
* class XIOFCDriver
|
||||
Driver specific for FC protocol.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
Addition of the X-IO volume driver will allow the end user to use X-IO storage
|
||||
as backend storage in Cinder.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
The driver can be configured with the following parameters in cinder.conf:
|
||||
* san_ip - IP to REST management interface on ISE
|
||||
* san_login - user name for REST management interface
|
||||
* san_password - password for user
|
||||
* ise_raid_level - RAID level for volumes
|
||||
* ise_default_pool - storage pool to use for volume creation
|
||||
* iscsi_ip_address - IP to one ISCSI target interface on ISE
|
||||
|
||||
The ISE ISCSI target interface specified in iscsi_ip_address will return all
|
||||
target portals available on that ISE, limited to the same subnet when receiving
|
||||
an ISCSI discover sendtargets request from a host identified as an Openstack
|
||||
host. This was added to allow the host to use multipathing, if enabled on the
|
||||
hypervisor.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Richard Hedlind
|
||||
|
||||
Primary assignee:
|
||||
rhedlind
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Common driver:
|
||||
xio_common.py
|
||||
Driver code common to FC and ISCSI.
|
||||
Done
|
||||
|
||||
ISCSI driver:
|
||||
xio_iscsi.py
|
||||
Driver code specific to ISCSI.
|
||||
Done. Passed driver cert test.
|
||||
|
||||
FC driver:
|
||||
xio_fc.py
|
||||
In progress. Code complete, but Driver cert in progress.
|
||||
|
||||
Unit test:
|
||||
test_xio_fc.py
|
||||
test_xio_iscsi.py
|
||||
In progress.
|
||||
|
||||
CI environment will be setup, one for each driver type.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Test using existing test infrastructure according to driver submission steps.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Support Matrix needs to be updated to include X-IO support.
|
||||
https://wiki.openstack.org/wiki/CinderSupportMatrix
|
||||
|
||||
Block storage documentation needs to be updated to include X-IO volume driver
|
||||
information in the volume drivers section.
|
||||
http://docs.openstack.org/
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
@ -1,180 +0,0 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================================================
|
||||
Add QoS, media affinity and thin allocation support to X-IO volume driver
|
||||
==========================================================================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/xio-volume-driver-1-1
|
||||
|
||||
This blueprint covers enhancements of X-IO volume driver to add support for:
|
||||
- QoS specs - add ability to pass down IOPSmin, IOPSmax and IOPSburst to
|
||||
ISE storage system.
|
||||
- Media affinity - add ability to pass down requested media type for volume.
|
||||
Media types supported: Flash, CADP (hybrid) and HDD only.
|
||||
- Add support for volume retype.
|
||||
- Thin allocation support.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
QoS support:
|
||||
Allow the end user to specify IOPSmin, IOPSmax and IOPSburst for a volume.
|
||||
|
||||
Affinity support:
|
||||
Allow the end user to specify media type for volume.
|
||||
|
||||
Volume retype support:
|
||||
Allow the end user to change the volume type for an existing volume.
|
||||
The volume will be updated to align with the new type accordingly.
|
||||
|
||||
Thin allocation support:
|
||||
Allow the end user to specify that the volume should be thinly allocated.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Extra specs and QoS specs for the specified volume type will be parsed and
|
||||
passed to the ISE storage system as part of the REST call to create volume.
|
||||
|
||||
Retype will use modify volume REST command to change volume attributes on ISE
|
||||
volume.
|
||||
|
||||
Extra-specs:
|
||||
Affinity:Type - specifies media type. Valid options: flash, cadp, hdd.
|
||||
|
||||
Example: To create volume type for flash media type.
|
||||
|
||||
cinder type-create flash Affinity:Type=flash
|
||||
|
||||
QoS-specs:
|
||||
QoS:IOPSmax - specifies max IOPS.
|
||||
QoS:IOPSmin - specifies min IOPS.
|
||||
QoS:IOPSburst - specifies burst IOPS.
|
||||
|
||||
Alloc:Type - specifies allocation type. Valid options: thin, thick.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None. Changes are local to X-IO volume driver.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None. Existing cinderclient commands are used to create volume-types
|
||||
that specifies QoS, affinity.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None. See above for new spec options supported.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
richard-hedlind
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Affinity support:
|
||||
Rework driver to support extra-specs in create_volume API.
|
||||
Affinity attribute will be copied from source volume in case of clone.
|
||||
|
||||
Implementation complete.
|
||||
|
||||
QoS support:
|
||||
Rework driver to support qos-specs in create_volume API. Implemented.
|
||||
QoS attributes will be copied from source volume in case of clone.
|
||||
|
||||
Implementation complete.
|
||||
|
||||
Retype:
|
||||
Add retype API to driver. API uses REST API modify volume to change attributes
|
||||
for existing volume.
|
||||
|
||||
Implementation complete.
|
||||
|
||||
Thin allocation:
|
||||
Pass down thin allocation flag if ISE storage array has support for it.
|
||||
|
||||
Implementation in progress.
|
||||
|
||||
Additional unit tests:
|
||||
Add unit tests to test out APIs for affinity, qos, retype, thin.
|
||||
|
||||
Implementation in progress.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Dependent on approval of base version of X-IO volume driver:
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/xio-iscsi-fc-volume-driver
|
||||
|
||||
https://review.openstack.org/#/c/116186/
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Test using existing test infrastructure according to driver submission steps.
|
||||
Tests will be added to test_xio.py to cover affinity, qos, retype and thin.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Support Matrix needs to be updated to include X-IO support.
|
||||
https://wiki.openstack.org/wiki/CinderSupportMatrix
|
||||
|
||||
Block storage documentation needs to be updated to include X-IO volume driver
|
||||
information in the volume drivers section.
|
||||
http://docs.openstack.org/
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
0
specs/kilo/get-vol-type-extra-specs.rst → specs/liberty/get-vol-type-extra-specs.rst
Executable file → Normal file
0
specs/kilo/get-vol-type-extra-specs.rst → specs/liberty/get-vol-type-extra-specs.rst
Executable file → Normal file
Loading…
x
Reference in New Issue
Block a user