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).
--
Gris Ge