On Wed, Dec 10, 2014 at 11:17:22AM -0800, Andy Grover wrote:
>6. Can NodeACLGroup automatically chose the host LUN ID like LUN
class do?
NodeACLGroup.mapped_lun()? You shouldn't need to give it a tpg_lun,
only the LUN to map it to. I don't think I understand this issue.
In LUN class,
we have these codes for find next available target LUN ID:
if lun is None:
luns = [l.lun for l in self.parent_tpg.luns]
for index in xrange(self.MAX_LUN+1):
if index not in luns:
lun = index
break
if lun is None:
raise RTSLibError("All LUNs 0-%d in use" % self.MAX_LUN)
else:
lun = int(lun)
if lun < 0 or lun > self.MAX_LUN:
raise RTSLibError("LUN must be 0 to %d" % self.MAX_LUN)
So I am expecting to have similar code in NodeACLGroup.mapped_lun() to find
next available host LUN ID.
>8. How to check whether a NodeACL is in a NodeACLGroup?
> Options A:
> NodeACL.tag
> # This require user know NodeACLGroup internal design.
> Options B:
> NodeACL.is_group_member # True or False
I thought we were trying to make it possible to use NodeACLGroups
with no NodeACL objects. Are you finding you still have NodeACL
objects?
To achieve backward compatibility in libstoragemgmt targetd plugin(at lest
we
try to), we still want to provide initiator level LUN mapping in targetd.
But for sure, it will be isolated from access group level LUN mapping.
That's why we need to know we are not touching any access group member there.
Instead if you have node_wwns:
if "iqn.2006-01.com.example:1234" in nag.wwns:
print "in the group"
Sounds reasonable.
>9. Should we store CHAP info in NodeACLGroup?
> Current design of LibStorageMgmt is initiator level CHAP setting
> with ONTAP[1] and targetd supported only.
> If we store CHAP info in NodeACLGroup, we cannot have back-ward
> compatibility on this in LibStorageMgmt which does not have group level
> CHAP level design yet.
>
> Options A:
> rtslibs does not change CHAP info when a NodeACL join NodeACLGroup.
> With this, member of NodeACLGroup could have different CHAP setting.
> The libstoragemgmt could get full backward compatibility.
>
> Options B:
> No change to current rtslibs design.
> Add group CHAP setting support to libstoragemgmt API.
> Break targetd backward compatibility.
> ONTAP still can get full backward compatibility.
I've also been looking at ONTAP as a model but had not noticed that
ontap igroups are not used for iscsi auth parameters, only lun
mappings.
https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-CF01DCCD-2C24-45...
All ONTAP manpage:
https://library.netapp.com/ecmdocs/ECMP1196890/html/#index
The ONTAP iSCSI manpage(including iSCSI CHAP -- 'iscsi security' command):
https://library.netapp.com/ecmdocs/ECMP1196890/html/man1/na_iscsi.1.html
Example command:
iscsi security add -i iqn.1994-05.com.redhat:test-netapp-2-way-chap \
-s CHAP -p redhat_out_pass -n redhat_out_user \
-o redhat_in_pass -m redhat_in_user
The 'in' and 'out' is for iscsi-initiator-utils:
node.session.auth.authmethod = CHAP
node.session.auth.username = redhat_out_user
node.session.auth.password = redhat_out_pass
node.session.auth.username_in = redhat_in_user
node.session.auth.password_in = redhat_in_pass
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = redhat_out_user
discovery.sendtargets.auth.password = redhat_out_pass
discovery.sendtargets.auth.username_in = redhat_in_user
discovery.sendtargets.auth.password_in = redhat_in_pass
Regards -- Andy
Thanks you very much for the kind feedback.
Best regards.
--
Gris Ge