wrong iscsi device path with SolidFire and SVIP/Vlan specifications

Bug #1619941 reported by Avishay Traeger
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Fix Released
Medium
John Griffith

Bug Description

This code assumes a specific format for the iscsi device path:
https://github.com/openstack/os-brick/blob/1.6.1/os_brick/initiator/connectors/iscsi.py#L546

Specifically "/dev/disk/by-path/ip-%s-iscsi-%s-lun-%s"

However, some systems include the port with the IP while others do not. My system based on Centos did this with a Solidfire target, while with other targets the port was not present. I've seen this on the Web as well: http://serverfault.com/questions/170617/howto-show-connected-targets-in-linux

When the port is included attach commands fail.

Changed in cinder:
assignee: nobody → John Griffith (john-griffith)
Revision history for this message
John Griffith (john-griffith) wrote :

I think you're hitting this because you're specifying an sf_svip entry without a port. I recently pushed an update to manuals to indicate this was needed:
    https://review.openstack.org/#/c/356685/
    (Bug: https://bugs.launchpad.net/openstack-manuals/+bug/1614243)

That being said, I can/should most certainly make the driver more robust and just use a default if you omit it in the conf entry. I'll go ahead and do that and associate it with this bug.

Thanks!

Changed in cinder:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (master)

Fix proposed to branch: master
Review: https://review.openstack.org/366475

Changed in cinder:
status: Triaged → In Progress
Revision history for this message
Avishay Traeger (avishay-il) wrote : Re: os-brick returns wrong iscsi device path

Thanks John, adding the port did the trick!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/370324

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on cinder (master)

Change abandoned by John Griffith (<email address hidden>) on branch: master
Review: https://review.openstack.org/366475
Reason: So this actually is addressed already (inadvertently) in one of the Cheesecake patches that unfortunately landed just after M closed:

https://review.openstack.org/#/c/299746/

Revision history for this message
John Griffith (john-griffith) wrote : Re: os-brick returns wrong iscsi device path

Note this actually only impacts releases prior to current stable (Newton). Patch to Mitaka proposed.

summary: - os-brick returns wrong iscsi device path
+ wrong iscsi device path with SolidFire and SVIP/Vlan specifications
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/mitaka)

Reviewed: https://review.openstack.org/370324
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=da77382f32ebe1f7f028054482fa1dceb1703530
Submitter: Jenkins
Branch: stable/mitaka

commit da77382f32ebe1f7f028054482fa1dceb1703530
Author: John Griffith <email address hidden>
Date: Wed Sep 14 11:13:14 2016 -0600

    Add iscsi port to sf_svip arg if not provided

    With things like VLAN support it may be necessary for
    an admin to specify the sf_svip (IP) address. The problem
    is that when this is specified if the admin forgets to include
    the port suffix to the SVIP address it may not work on certain
    distros (inparticular RHEL variants).

    This patch just adds a simple check when the endpoint is created
    to make sure the port suffix is included, if it's not it
    automatically adds the default 3260.

    NOTE: This is not a backport, the Cheesecake code has an
    inadvertent fix (albeit it could be improved) that didn't
    merge in Mitaka.

    Change-Id: Id2a99ff927d1fb9e40fab10beb0db5e4f302ae70
    Closes-Bug: #1619941

tags: added: in-stable-mitaka
Changed in cinder:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.