On 11/27/2014 12:31 AM, Gris Ge wrote:
NodeACL and MappedLUN are still used internally, but the API can be *Group classes and wwn strings entirely I think. It could be good.
Correct. If we have NodeACLGroup introduced, changing NodeACL as private/internal could be better. Or we will have two set of mapping work flow.
Maybe something like for #1 could be: NodeACLGroup.initiators() return ([wwn, ], [wwn_type])
Well what everyone else calls "initiators", LIO and rtslib call NodeACLs, so instead of using both words I think we would just stick with NodeACLs for consistency. So, have a NodeACLGroup.node_acls property that returns member wwns as strings.
What do you mean by wwn_type? All members of a group are within a tpg, which is within a target, which is of a fabric type (iscsi, etc.) so wwn_type should always be the same for all members of a group.
For #2: To hide NodeACL, we should do nodeacl.delete() inside of NodeACLGroup.remove_acl().
OK cool. That's what the commit I pushed last week does.
That's not the reverse, nag.mapped_luns gives MappedLUNGroups. The reverse is MappedLUNGroup.parent_nodeaclgroup. (Should we change nag.mapped_luns property name to nag.mapped_lun_groups perhaps?)
No MappedLUNGroup.parent_nodeaclgroup is not what I am looking for.
I am seeking a way to query a list of NodeACLGroup which have access to defined lun.
You can do this with a little work. Right now I am leaning towards targetd doing this work instead of rtslib -- rtslib should provide ways to get other immediately relevant objects but this is beyond that.
If MappedLUNGroup is a relationship from LUN to NodeACLGroup, then we might allow query this relationship in both directions:
1. Query out which NodeACLGroups have access to LUN /tmp/lun_01. 2. Query out which LUNs does NodeACLGroup test_ag_01 have access to.
OK, we can add MappedLUNGroup.tpg_lun, since all members of a MappedLUNGroup should refer to the same LUN. Then targetd can do:
def nags_using_lun(tpg, lun): matches = set() for nag in tpg.node_acl_groups: for mlung in nag.mapped_luns: if mlung.tpg_lun == LUN: matches.add(nag) return matches
or something.
Hopeful this wish list might help:
- Query NodeACLGroup and its initiator wwn, wwn_type, chap settings.
- initiator wwns, multiple, ok
- wwn_type, see above, should be able to get that from nag.parent_tpg.parent_target.fabric_module.name
- chap settings. should work.
- LUN mapping and unmap.
add for group with nag.mapped_lun(), unmap, first get the MappedLUNGroup object, then call MappedLUNGroup.delete().
- Add/Remove initiator into exist NodeACLGroup.
add_acl and remove_acl, ok
# Copy/Revoke existing mapping status and CHAP setting.
ok.
- Create NodeACLGroup with its first initiator. # New NodeACLGroup should hold no mapping or CHAP setting.
- Delete NodeACLGroup which delete initiator and their mapping, chap settings.
I think the way we want to go on this is that it's ok to have a NodeACLGroup with no members. This may happen before any members are added, or after the last one is deleted. We can tell if it's empty with NodeACLGroup.exists. NodeACLGroup.delete() still leaves a Python object in scope, it just doesn't refer to any NodeACLs, and .exists will return False.
- Get a list of LUN (maybe a list of target lun id) which current NodeACLGroup mapped to.
See above, doable in targetd if we have MappedLUNGroup.tpg_lun property.
- Get a list of NodeACLGroup (maybe a list of NodeACLGroup name) which current LUN mapped to.
MappedLUNGroup.tpg_lun should allow this too.
- Not allow empty NodeACLGroup.
Allowed but can test with NodeACLGroup.exists.
new stuff pushed to dev-groups github branch[1].
Regards -- Andy