Comment 1 for bug 1275312

Okay, examples of my configuration (only relevant primitives shown):

primitive iscsi_vip ocf:heartbeat:IPaddr2 \
        params ip="172.28.196.105" cidr_netmask="25" \
        op monitor interval="30s" \
primitive p_map_cvstor0 ocf:ceph:rbd \
        params user="nfshead" pool="rbd" name="cvstor0" cephconf="/etc/ceph/ceph.conf" \
        op monitor interval="10s" timeout="20s"
primitive p_lun_cvstor0 ocf:heartbeat:iSCSILogicalUnit \
        params target_iqn="iqn.2014-01.net.acme.company:cvstor0" lun="1" path="/dev/rbd/rbd/cvstor0" implementation="lio"
primitive p_target_cvstor0 ocf:heartbeat:iSCSITarget \
        params iqn="iqn.2014-01.net.acme.company:cvstor0" implementation="lio" allowed_initiators="iqn.1991-05.com.microsoft:mcs-e-comm-man5" portals="172.28.196.105:3260" \
        op monitor interval="30s"
colocation c_g_cvstor0_with_ip inf: g_cvstor0 iscsi_vip
order o_g_cvstor0_after_vip inf: iscsi_vip g_cvstor0
order o_cvstor0_lun_after_target inf: p_target_cvstor0:start p_lun_cvstor0:start
order o_cvstor0_target_after_map inf: p_map_cvstor0:start p_target_cvstor0:start

This will correctly mount the RADOS block device, create the target and LUN and the ACLs, but doesn't perform the last step of mapping the LUN to the ACL, thus the initiator is unable to see the LUN after connecting successfully to the target.

From targetcli (snipped for relevance again):

  o- iscsi ......................................................... [7 Targets]
  | o- iqn.2014-01.net.ukfast.ecloud:cvstor0 ........................... [1 TPG]
  | | o- tpgt1 ....................................................... [enabled]
  | | o- acls ........................................................ [1 ACL]
  | | | o- iqn.1991-05.com.microsoft:mcs-e-comm-man5 .......... [0 Mapped LUN] <---- This is the problem
  | | o- luns ........................................................ [1 LUN]
  | | | o- lun1 ................ [iblock/p_lun_cvstor0 (/dev/rbd/rbd/cvstor0)]
  | | o- portals .................................................. [1 Portal]
  | | o- 172.28.196.105:3260 .......................................... [OK]

The code highlighted in my initial report from Github resolves this mapping issue.