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
[1]
https://github.com/agrover/rtslib-fb/pull/56