Hi Andy,
On Tue, 18 Nov 2014 17:39:56 -0800, Andy Grover wrote :
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)
There seems to be more than one public user of rtslib-fb. I see that
rtslib-fb (but not configshell-fb or targetcli-fb) is now part of
Debian. It is used by some OpenStack components:
$ apt show python-rtslib-fb | head
Package: python-rtslib-fb
Version: 2.1.45-4
Installed-Size: 186 kB
Maintainer: PKG OpenStack <openstack-devel(a)lists.alioth.debian.org>
Provides: python2.7-rtslib-fb
Depends: python (>= 2.7), python (<< 2.8)
Suggests: python-rtslib-fb-doc
Conflicts: python-rtslib, rtsadmin-frozen
Homepage:
https://github.com/agrover/rtslib-fb
[...]
$ apt-cache rdepends python-rtslib-fb
python-rtslib-fb
Reverse Depends:
python3-rtslib-fb
python-cinder
[...] 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.
Looks nice.
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.
Just curious: what are the differences between rtslib and rtslib-fb that
can cause misbehaviours in scripts?
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?
--
Christophe Vu-Brugier