Re: Fwd: initiator group support in rtslib
by Andy Grover
On 11/26/2014 01:17 AM, Gris Ge wrote:
> On Tue, Nov 25, 2014 at 07:54:50AM -0800, Andy Grover wrote:
>> Hi Gris, saw your irc msg.
>>
>> Fwding an email I sent to targetcli-fb and targetd lists, not sure
>> if you're on those. But yes, I was not going to merge the rtslib
>> changes until we knew that they were what we needed for targetd. It
>> sounds like you're signed up for the targetd work, so please let me
>> know of any bugs you find or API changes to rtslib that would make
>> your work easier.
>>
>> And then once we're happy with both, we can commit to both repos.
>>
>> Thanks! -- Andy
>>
> Hi Andy,
Hi Gris. I'm CCing the lists on my response, just for the sake of having
good technical discussions like this in public.
> 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.
> #
> # My understanding of initiator group is:
> # * Volume mapping status is maintained at group level.
> # * Initiator in this group just inherit that mapping status.
> # * Initiator add or remove means grant or revoke that inheritance.
>
> 3. It seems we have no quick way to query masked NodeACLGroup for
> given LUN.
> # We have the revert one:
> # nag = NodeACLGroup(tpg, nag_name)
> # nag.mapped_luns()
> #
> # I am expecting something like this:
> # lun = LUN(tpg, lun=<target_lun_id>, storage_object=<st_obj>)
> # lun.mapped_node_acl_groups()
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?)
> 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?
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.
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 :)
Thanks! -- Regards -- Andy
9 years, 3 months
initiator group support in rtslib
by Andy Grover
Hi all,
I've pushed a "dev-groups" branch to rtslib-fb github, and opened a pull
request:
https://github.com/agrover/rtslib-fb/pull/56
which implements NodeACLGroup and MappedLUNGroup classes. These present
grouped views of the underlying NodeACL and MappedLUN objects.
I've done some unit testing but I'm planning on using adding initiator
group support to targetd to find gaps and usability issues with this new
rtslib code before merging it.
We will also want to switch targetcli from using its own code to support
groups, to using the support in rtslib, but that work need not be done
immediately.
Thanks -- Regards -- Andy
9 years, 5 months
future work: rtslib
by Andy Grover
Hi all,
I just wanted to ruminate in public about what I'm thinking about
working on, in case anyone had input.
The first thing is initiator groups -- being able to configure NodeACLs
as a group instead of individually. Currently rtslib has support for a
nodeacl 'tag' attribute. Targetcli leverages this to support 'tag' and
'untag' commands, that present multiple nodeacls as one.
However, now the other user of rtslib-fb (at least the only other public
user) targetd now needs to support initiator groups so it can work
properly with libstoragemgmt. Instead of duplicating the code that's in
targetcli, I'm thinking it would probably be better to add support into
rtslib itself.
I've started working on a NodeACLGroup class to do this. The NodeACL
class will remain, and the only other change should be a new tpg
node_acl_groups property, so this new capability should be backwards
compatible.
The other thing I've been thinking about is rtslib and rtslib-fb
co-installability. Achieving this would be a first step towards unifying
development, which rtslib developer Jerome and I have discussed a
little. While of course their APIs have diverged, what's worse is that
they share the same import name. Thus the author of a script using
rtslib on Debian, upon moving to RHEL, (or vice versa) will find the
library is present but likely misbehaves at runtime.
I've experimented with some Python magic to somehow determine at runtime
what to do to make everything work... but it doesn't seem practical.
Yup, I really should have changed the import name to rtslib-fb when -fb
was originally created. Very very bad in retrospect.
What we can do, however, is fix this for future Fedora and RHEL releases
by moving to "rtslib-fb" as the import instead of "rtslib". We could
also move to "rtslib-fb" for Python 3 package versions of rtslib on
existing releases, since presumably those have ~zero users. Then Datera
rtslib and rtslib-fb would at least have a prayer of being
co-installable (although I'm sure there might be some other issues to
work out too). The only laggard would be RHEL7, where we'd be unable to
rename things without an impermissible API break.
Thoughts?
Regards -- Andy
9 years, 5 months
Debugging AttributeError: 'module' object has no attribute 'kmod'
by Christophe Vu-Brugier
Hi Andy,
I am working on better integrating targetcli in Buildroot. Buildroot
is an easy to configure build system that uses cross compilation to
generate tiny root file systems for embedded platforms.
Buildroot supports systemd so I built a root file system with
targetcli and systemd. When systemd is selected as the init system in
Buildroot, the python-kmod module is also built by Buildroot (because
kmod is a dependency of systemd). And since python-kmod is present,
targetcli tries to use it. But it fails with the following error:
# targetcli
Traceback (most recent call last):
File "/usr/bin/targetcli", line 100, in <module>
main()
File "/usr/bin/targetcli", line 63, in main
root_node = UIRoot(shell, as_root=is_root)
File "home/cvubrugier/repos/buildroot/output/x86-targetcli-systemd/target/usr/lib/python3.4/site-packages/targetcli/ui_root.py", line 44, in __init__
File "home/cvubrugier/repos/buildroot/output/x86-targetcli-systemd/target/usr/lib/python3.4/site-packages/rtslib/root.py", line 66, in __init__
File "home/cvubrugier/repos/buildroot/output/x86-targetcli-systemd/target/usr/lib/python3.4/site-packages/rtslib/utils.py", line 364, in modprobe
AttributeError: 'module' object has no attribute 'Kmod'
Trying to use python-kmod by hand also fails on the system.
Python 3.4.1 (default, Oct 29 2014, 13:37:35)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import kmod
>>> km = kmod.kmod()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'kmod'
Maybe python-kmod is not properly built. Do you have some advises of
what I should look at to debug this issue.
Best regards,
--
Christophe Vu-Brugier
9 years, 5 months
targetcli bug?
by Leeman Strout
Not sure what sort of debugging to do or what data you need here, but I
think I've run into a bug with targetcli shell 2.1.fb37.
/backstores/block> create ib_Games-spectre /dev/data2/Games-spectre
Created block storage object ib_Games-spectre using
/dev/data2/Games-spectre.
/backstores/block> ls
o- block .................................................. [Storage
Objects: 4]
o- ib_Games-spectre [/dev/data2/Games-spectre (300.0GiB) write-thru
deactivated]
o- ib_Games-stereo . [/dev/data2/Games-stereo (300.0GiB) write-thru
activated]
o- ib_Games-wyvern . [/dev/data2/Games-wyvern (300.0GiB) write-thru
activated]
o- ib_Games-zapdos . [/dev/data2/Games-zapdos (300.0GiB) write-thru
activated]
/backstores/block> cd /
/> ls
o- /
..................................................................... [...]
o- backstores
.......................................................... [...]
| o- block .............................................. [Storage
Objects: 3]
| | o- ib_Games-stereo [/dev/data2/Games-stereo (300.0GiB)
write-thru activated]
| | o- ib_Games-wyvern [/dev/data2/Games-wyvern (300.0GiB)
write-thru activated]
| | o- ib_Games-zapdos [/dev/data2/Games-zapdos (300.0GiB)
write-thru activat
... truncated ...
Exiting targetcli and re-executing provides the expected results to an
ls command in spite of any path changes, the new block backstore doesn't
disappear.
Let me know if there's anything additional I can provide.
Leeman
Distro: Arch
Linux server 3.17.2-1-ARCH #1 SMP PREEMPT Thu Oct 30 20:49:39 CET 2014
x86_64 GNU/Linux
local/python-configshell-fb 1.1.fb15-3
python framework for building simple CLI applications (free branch)
local/python-rtslib-fb 2.1.fb50-1
free branch version of the LIO target API
local/python2-configshell-fb 1.1.fb15-3
python framework for building simple CLI applications (free branch)
local/targetcli-fb 2.1.fb37-1
free branch of the targetcli LIO administration shell (iSCSI + Co)
9 years, 5 months