Comment 9 for bug 1732199

On studying this quite a bit more ... I was confused about what caused SCSI host 23 to appear (syslog) at 10:55:26. It wasn't anything to do with the volume extend test - that was using host 22, which was created by the login at 10:55:19. It wasn't anything that c-vol was doing at the time ... so what was it? Then I realised that c-bak could have been doing something aswell. Sure enough:

Sep 24 10:55:26.003013 ubuntu-xenial-rax-ord-0002235107 cinder-backup[16673]: DEBUG oslo.privsep.daemon [-] privsep: request[140306203894800]: (3, 'os_brick.privileged.rootwrap.execute_root', ('iscsiadm', '-m', 'node', '-T', u'iqn.2010-10.org.openstack:volume-b8059959-d35e-4567-86cd-a2094e8a5fff', '-p', u'10.210.68.187:3260', '--login'), {'attempts': 1, 'check_exit_code': (0, 15, 255), 'delay_on_retry': True}) {{(pid=11439) loop /usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py:443}}

So I tried adding a target manually, then I discovered it on the initiator, then did "iscsiadm -m node -l", whilst continually doing 'iscsiadm -m session'. It reproduced this:

iscsiadm: could not read session targetname: 5
iscsiadm: could not find session info for session519

for a few seconds, then went back to normal.

So, it appears that logging into a new target causes a temporary failure to list sessions. Seems like this may be a bug in the iscsi initiator implementation.