On 12/04/2014 08:27 AM, Gris Ge wrote:
Hi Andy,
Hi Gris,
I am working on masking issue.
But here are some issues I found for now:
1. NodeACLGroup.node_acls
A list of string(wwn).
# Renamed to NodeACLGroup.wwns?
TPG.node_acls
A list of NodeACL
OK, makes sense.
2. NodeACL.mapped_luns
A list of MappedLUN
NodeACLGroup.mapped_luns
A list of MappedLUNGroup
# Renamed to NodeACLGroup.mapped_luns
I don't understand. Did you mean to say it should be renamed to
NodeACLGroup.mapped_lun_groups?
3. User case of maintaining the consistance of mapping status.
Example:
Current debugfs status:
configfs :)
IQN_1 LUN_1
AG_1
INIT_2 LUN_2, LUN_3
INIT_3 LUN_2, LUN_3
Got a API request:
Map LUN_4 to INIT_2
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.
We have an existing low-level API via NodeACL class, that NodeACLGroup
even uses. Users should never mix the low-level API (NodeACL) with the
higher-level API (NodeACLGroup). We don't have a way to prevent this in
the code so we just need to make it very clear in the documentation. I
think that's the best we can do. We should discourage the use of
NodeACL, and maybe some day we can deprecate and remove it as a public API.
Which layer should handle the check and error raise if needed?
A. user itself or upper app/lib.
B. targetd/targetcli
C. rtslibs
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.
4. The 'lun' sometimes refer to LUN class object, while
sometimes refer to a integer number of target side LUN ID.
The 'mapped_lun' sometimes refer to object of MappedLUN or integer number of
host side LUN ID.
True. But we cannot change what exists in NodeACL or MappedLUN classes.
At least in the *Group versions we can be consistent with their
inconsistency :-)
Regards -- Andy