On Wed, Nov 26, 2014 at 08:12:08PM -0800, Andy Grover wrote:
Hi Gris. I'm CCing the lists on my response, just for the sake of
having good technical discussions like this in public.
Hi Andy,
>These might make targetd life easier:
>
> 1. Change NodeACLGroup._node_acls as a public property.
> # It is require to get a list of group member NodeACL
I did agree, but then changed my mind, based on the below.
> 2. How about let NodeACLGroup.remove_acl() remove mapping status
> also?
> # If not, targetd have to do the mapping removal when remove a
> # initiator(ACL) from a initiator group(NodeACLGroup).
nodeacl.delete() deletes the nodeacl as well as any mappedluns within it.
> # It means targetd will use both initiator mapping and group
> # mapping.
> #
> # I thought the intention of adding NodeACLGroup and MappedLUNGroup is
> # to hide/replace the NodeACL and MappedLUN. Is it?
I wasn't sure, to be honest. How would this work? No methods in
NodeACLGroup or MappedLUNGroup would take or return NodeACLs or
MappedLUNs. This would mean #1 suggestion above should not be done.
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])
For #2:
To hide NodeACL, we should do nodeacl.delete() inside of
NodeACLGroup.remove_acl().
> 3. It seems we have no quick way to query masked NodeACLGroup
for
> given LUN.
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.
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.
> 4. NodeACLGroup.add_acl() didn't override old iSCSI CHAP
setting.
It doesn't? That's what the "if model.has_feature("auth")"
section
was supposed to do. Is that not working right? Or are you referring
to something else that was missed?
Oh. I didn't test it just never found that
line.
OK I'm going to update the dev-groups branch to change the usage
model to be more that users just use Group'd class versions
exclusively. I think just add_acl and remove_acl have to change.
Hopeful this wish
list might help:
* Query NodeACLGroup and its initiator wwn, wwn_type, chap settings.
* LUN mapping and unmap.
* Add/Remove initiator into exist NodeACLGroup.
# Copy/Revoke existing mapping status and CHAP setting.
* 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.
* Get a list of LUN (maybe a list of target lun id) which current
NodeACLGroup mapped to.
* Get a list of NodeACLGroup (maybe a list of NodeACLGroup name)
which current LUN mapped to.
* Not allow empty NodeACLGroup.
Not tested, sorry. BTW USA workers have Thursday and Friday off so I
won't be around, but if this change is an improvement then we can
sync up on Monday, and if it's not, then we can also sync up on
Monday :)
Enjoy the Thanksgiving, especially Black Friday! :)
Thanks! -- Regards -- Andy
Thank you.
Best regards.
--
Gris Ge