Bug 1697996

+++ This bug was initially created as a clone of Bug #1697994 +++

NetApp iSCSI drivers use discovery mode for multipathing, which means
that we'll fail to attach a volume if the IP provided for the discovery
is not accessible from the host.

Something similar would happen when using singlepath, as we are only
trying to connect to one target/portal.

This bugzilla is for backporting to  RHOSP 13 platform this particular patch changes NetApp drivers so the return target_iqns, target_portals, and target_luns parameters whenever there are more than
one option.

Hello RHEL Product and Program Management team, do we have a timeline
on when this will be backported to OSP13? Looks like this is on QA right now.

Hi Bala,

We can only give the target timeline for the RHOS (openstack) erratta update this will ship in, which is currently the end of June but may be first week of July.  We work to release erratta release updates every 4-6 weeks, but the schedule can move a little depending on other activies that arise such as CVE releases etc.  Should be out in that timeframe.

Thanks,
Paul

Hi Paul

Sounds good. Hopefully this can be included in the errata update that comes out in the last week of June/first week of July. Thank you for your response

Verified on:
openstack-cinder-12.0.7-1.el7ost.noarch

We created a netapp iscsi volume:

(overcloud) [stack@undercloud-0 ~]$ cinder create 3 --volume-type netapp --name netappvol
+--------------------------------+--------------------------------------+
| Property                       | Value                                |
+--------------------------------+--------------------------------------+
| attachments                    | []                                   |
| availability_zone              | nova                                 |
| bootable                       | false                                |
| consistencygroup_id            | None                                 |
| created_at                     | 2019-06-18T06:36:39.000000           |
| description                    | None                                 |
| encrypted                      | False                                |
| id                             | ddf8813a-e695-416c-b6fe-7c9d05060ab5 |
| metadata                       | {}                                   |
| migration_status               | None                                 |
| multiattach                    | False                                |
| name                           | netappvol                            |
| os-vol-host-attr:host          | hostgroup@netapp#rhos_infra_tlv2     |
| os-vol-mig-status-attr:migstat | None                                 |
| os-vol-mig-status-attr:name_id | None                                 |
| os-vol-tenant-attr:tenant_id   | 88a400971a2f4dc1837515da5dcc1679     |
| replication_status             | None                                 |
| size                           | 3                                    |
| snapshot_id                    | None                                 |
| source_volid                   | None                                 |
| status                         | creating                             |
| updated_at                     | 2019-06-18T06:36:39.000000           |
| user_id                        | 1c4dc349d9424a028c4ea18331473354     |
| volume_type                    | netapp                               |
+--------------------------------+--------------------------------------+

We attach the volume to an instance
(overcloud) [stack@undercloud-0 ~]$ nova volume-attach 9e5d7e67-3295-4c38-b395-88705546a164 ddf8813a-e695-416c-b6fe-7c9d05060ab5 auto
+----------+--------------------------------------+
| Property | Value                                |
+----------+--------------------------------------+
| device   | /dev/vdc                             |
| id       | ddf8813a-e695-416c-b6fe-7c9d05060ab5 |
| serverId | 9e5d7e67-3295-4c38-b395-88705546a164 |
| volumeId | ddf8813a-e695-416c-b6fe-7c9d05060ab5 |
+----------+--------------------------------------+


Mulitpath device created on compute
[root@compute-1 ~]# multipath -ll
3600a09803830447a4f244c4657595731 dm-0 NETAPP  ,LUN C-Mode      
size=3.0G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 27:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 26:0:0:0 sda 8:0  active ready running

We see both target portals 
[root@compute-1 ~]# iscsiadm -m session -P 3 | grep 16
Target: iqn.1992-08.com.netapp:sn.1b60aa2ba3ab11e8911600a098d00ab0:vs.5 (non-flash)
        Current Portal: X.y.16.12:3260,1042
        Persistent Portal: x.y.16.12:3260,1042
                Iface IPaddress: 192.168.24.17
        Current Portal: x.y.16.11:3260,1041
        Persistent Portal: x.y.16.11:3260,1041
                Iface IPaddress: 192.168.24.17


Good to verify as we see both IPs/ports.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:1732

*** Bug 1735269 has been marked as a duplicate of this bug. ***