cinder-specs/specs/liberty/brick-add-open-iscsi-transport-suppport.rst
Ivan Kolodyazhny fa11db5278 Remove hardcoded releases list from unit tests
test_titles had hardcoded releases list and 'liberty' folder was out of
scope for this test.

Also all specs were changed to fit template and pass tests.

Change-Id: Ib4c6cbb96a9f9c96dd54cff3b92a35c35df72fff
2015-10-05 23:31:43 +03:00

4.6 KiB

Allow brick to support other iSCSI transports besides TCP

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/cinder/+spec/brick-add-open-iscsi-transport-support

Currently open-iscsi in openstack does not allow the use of offload iscsi transports (cxgb4i, qla4xx, bnx2i etc) or other software iscsi transports (like iser). This blueprint aims to add support for this

Problem description

open-iscsi has hardware iSCSI transport support. The interface argument specifies the hardware iSCSI interface to use for the operation. Any hardware vendors that currently provide hardware interfaces for open-iscsi cannot use them in openstack as the interfaces (iface) argument is not currently supported in the iSCSI driver.

Use Cases

Use of such iSCSI hardware transports requires providing a corresponding interface file (referred to as iface), which can be autogenerated via iscsiadm but need correctness checks or can also be generated on the fly, given the 3-tuple of ipaddress, hwaddress & transport name to be used. The iface format itself is generic and does not use any propreitary fields irrespective of transport being used.

These changes are already in nova, code can be seen here : https://review.openstack.org/#/c/146233/

This will also enable use of iSER directly through the iSCSI driver, though deprecating the iSER driver is not the aim of this spec, and will probably start with iSER disabled, (and also because iSER requires target support unlike hardware transports)

Proposed change

On the initiator side the only difference between using software iSCSI and hardware iSCSI transport is the interface flag (--interface=[iface])

e.g. "iscsiadm -m discovery -t st -p ip:port -I <iface file>"

iface files can automatically be generated for all hardware present on a system that is supported by open-iscsi by 'iscsiadm -m iface'. The default format for iface file names is in the form <transport_name.hw_address>

The default iface name is 'default'. Not using the -I parameter (which is how open-iscsi is currently being used in nova) is the same as specifying

'iscsiadm -m discovery -t st -p ip:port -I default'

Required changes are :

  • A new parameter to specify which transport should be used while doing iscsi discovery/login, falling back to TCP if operation does not succeed, or if parameter is not provided (-I default)
  • Offloaded transports use the device path with a prefix pci-0000:00:00.0-, change related code to handle this

Alternatives

Use manual discovery of iscsi-targets, and provide -I parameter when doing discovery. Transport names are written in the resultant records generated by open-iscsi, however this does not guarantee hardware transports will be used, as this can be overridden with depending on how cli params are constructed.

Data model impact

None

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

Actual iSCSI performance can generally be improved by using transports over iscsi_tcp, no other impact.

Other deployer impact

This can be used to deprecate the separate iSER connector, as use of iser simply implies providing -I iser param to iscsiadm

Developer impact

Implementation

Assignee(s)

Primary assignee:

anish7 <anish@chelsio.com>

Work Items

  • Add -I parameter to all iscsiadm login/discovery commands currently being used in brick
  • Add prefix support to _get_device_path()

Dependencies

None as such. However, the minimum information required for using a tansport if it is not already configured is a 3 tuple of ip, transport name & hardware address.

Testing

Current iSCSI tests will work just fine, run separately using a faux transport (open-iscsi already supports this ability)

Documentation Impact

Use of transport ifaces will need relevant documentation.

References