On Thu, Dec 04, 2014 at 12:18:06PM -0800, Andy Grover wrote:
On 12/04/2014 08:27 AM, Gris Ge wrote:
I don't understand. Did you mean to say it should be renamed to NodeACLGroup.mapped_lun_groups?
Yes, NodeACLGroup.mapped_lun_groups. Sorry for my typo.
Expected behaviour: A. Raise error as INIT_2 is a member of Access Group. Refuse initiator level mapping. B. Map the LUN_4 to AG_1. C. Map the LUN_4 to INIT_2 only and leave the mess to end-user.
Unfortunately I think option C. To do option A, we would need to make previously ok use of NodeACL now raise an error.
If the client is not using NodeACL then this condition cannot happen :)
There's always going to be the ability to go around and make a mess (inconsistent group members) because it's all just a wrapper around LIO's configfs tree, which has no groups, only individual nodeacls and tags.
Make sense. I will do the initiator/access_group isolation at targetd level.
Regards -- Andy
Hi Andy,
Please kindly comment on these issues also:
5. list(NodeACLGroup('not_exist_group_tag').mapped_luns) # Got IndexError("Group is empty") list(NodeACL(tpg, 'iqn.2000-04.not.exist:iqn').mapped_luns) # Got []
6. Can NodeACLGroup automatically chose the host LUN ID like LUN class do?
7. What's the maximum number of host LUN ID(NodeACLGroup.mapped_lun)? LUN.MAX_LUN?
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
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 am in a favor of option A which provide possible full backward compatibility
I also attached demo[2] patches for targetd and libstoragemgmt for quick test. The demo patch enabled targetd and libstoragemgmt with these features: 1. Access group create/destroy/query. 2. Add or remove initiator to/from access group. 3. Access group volume mask/mapping create/destroy/query.
Clearly, this indicate current design of rtslibs works and meet all libstoragemgmt access group requirements[3].
Looking forward to the next round of rtslibs changes.
Thank you very much for the great work. Have a good weekend.
[1] ONTAP has a very good access group(igroup) support, but they still using initiator level CHAP setting, not group level. That's why libstoragemgmt in first place design initiator level CHAP.
[2] Still have many TODOs there, the biggest one is backward compatibility. [3] Except the CHAP thing mentioned in issue 9).