Hi Andy and everyone on the list,
Andy and I managed to discuss a reunification of the rtslib/targetcli
stack over the phone, so here is a quick summary of that, along to my
reply to Andy's last email quoted below.
Andy and I discussed some of the users problematics, we talked about use
cases for the stack, and of our respective goals regarding what we think
we should support. It happens that our views, biased by our respective
environments and jobs, are IMO complementary. Which is good.
We agreed that the cornerstone of the reunification is rtslib. We need
to find a way to unify that brick. This part is twofold:
- The configfs manipulation API
- The configuration save/restore logic
In order to get started, our next step will be to lay down the actual
API differences and how to reconcile those while preserving
compatibility as much as possible. Andy and I discussed a few ideas to
explore in order to achieve this, but ultimately the options will depend
on what we find when diff'ing the two APIs.
On 08/05/2014 07:57 PM, Andy Grover wrote:
On 08/05/2014 02:05 AM, Jerome Martin wrote:
As for extra features aimed at commercial users, I am not sure what
you are referring to here. Are those commercial users Datera's
customers?
This was referring to other features like loadable fabric configs. You
said it was a requirement and I assumed it came from Datera.
We discussed that a little bit, and mostly I guess the misunderstanding
comes from the angle we look at things. Andy has the RHEL prism, and I
am more in contact with "users in the wild", not necessarily using a
packaged kernel with a single set of supported fabrics. Also, some other
things we discussed are usecases for rtslib, and here too Andy and I
tend to be familiar with different types of users. I see more of the
"python-scripting" type, directly using rtslib from python, and Andy has
more "targetcli-scripting" types. Both usage scenarios are valid, and
both should be equally well supported.
Let me be a little bold here, nothing personal though, but this needs to
be said.
You decided to fork my original code, which is great, and you had your
reasons. So far, so good. But then you _decided_ to break API and
compatibility. Given your position, that meant imposing that
incompatible version on all RH users. Given the weight of RH-base
distros, that means that you effectively painted both of us in a corner,
with contributors and users somehow in between, feet covered in wet
paint. And here we are now, with a mess to clean up, Debian users
writing scripts and configs that won't work on RHEL, etc.
OK, what would we need to do to support Debian users across a
transition? Datera targetcli doesn't support scripting. Configs have no
state that is not put into configfs, so a config applied to it by one
system can be read back and saved in another format. Debian rtslib API
users, then? AFAIK there are no packaged apps other than targetcli and
targetd that use the rtslib API. So we're left with users who have
written custom apps or Python scripts against rtslib.
So, yes, this is the point, but supporting those scripts is still
important because there _are_ plenty of those in the wild. As said
above, we discussed that and agreed that we should try not to break those.
There really aren't that many API differences, actually. If we alias
BlockStorageObject back to IBlockStorageObject? Other than that,
rtslib-fb removed all the Backstore classes (not actually needed), would
we need to bring them back in a compatibility shim?
So, after talking about it, there is definitely more to it than just
that. But again, we need to first assess exactly the gap before knowing
what the options are. Andy and I both agreed on principle to prioritize
the time to do it. No fixed deadline though, this will have to best best
effort for now.
Of course, you can't take the blame alone. I have my responsibility in
it too. I won't deny it. It takes two (at least) to tango. I'll leave it
to you to expand on that if you feel like it :-)
I don't accept any blame and I don't put any blame on you Jerome.
OK, I don't think we talked about it :-)
Well, let's say that we agree to disagree.
There's work to be done but I can imagine worse starting points.
Pretty much the consensus after our phone call, yes.
As for the "how", I think we need to structure the problem a little bit
here.
1) rtslib - This is the cornerstone. First goal should be to have a
common rtslib, no matter what we build on top of it. I am ready to
discuss API points at your convenance, whether the config API should be
part of it or split, etc. But at least let's give us a common platform
to implement locking, etc.
I disagree a little. The kernel's configfs API is the cornerstone. So
for locking, we need a standard that is at that level, as well as an
implementation in rtslib. There are already alternative LIO APIs in Perl
and shell for example, and there are bound to be more.
If locking gets implemented on the kernel side, them of course it should
be supported at the rtslib level, so that several rtslib instances along
with whatever runs alongside in perl or bash can use the configfs if
needed. Even if it does not (I have no clue if this is a good idea or
not, you guys doing the kernel bits know better), we could implement a
convention at that level for userspace. No problem with that.
My original comment was made with something different in mind though. I
was anticipating concurrent usage of a single instance of rtslib - with
a remote API on top for instance - or concurrent targetcli/lio shell
usage on one system. In both cases, the new config API - part of rtslib
- could provide partial locking per target, of even per target
subsystem. This is different from the low-level locking that Andy
mentions, and has more to do with semantics for concurrent access to the
"system configuration" abstraction provided by the new config API.
But yes, in other areas I agree the library is extremely important.
I never doubted it :-)
2) targetcli - Well, in the main branch, targetcli is going to be
deprecated eventually - post 3.x, as announced before - in favor of the
new lio shell with configuration API semantics. So I feel unification of
existing the targetcli versions is not that important, but we could
decide to work together on the new lio shell.
I'm going to be supporting targetcli for a long time. Moving to a new
shell is going to require much discussion.
So, this would be the step after rtslib unification. For support policy
reasons, RHEL7 and before need to continue to maintain the included
targetcli 2.x series. This is understandable and perfectly fine.
In the 3.x series, the shell is still targetcli, with a separate preview
of a config API based shell. In that separate shell, the semantic is not
anymore based on direct imperative manipulation of the configfs nodes
and attributes, but instead working with a candidate configuration that
can be manipulated, backed-up, rolled back, merged, imported and
exported before being verified and then committed to the system. The two
levels of abstraction could coexist, although I feel the saner default
would be the later.
3) remote API - You already have that targetd thing, but this is very
low-level and I feel not so safe even with locking. What I have in mind
is to leverage the config API semantics to eventually provide
higher-level access to target configuration. We could easily join forces
on this.
Sure. I have no idea what a higher level API would look like. targetd is
an attempt to leverage LIO and LVM to present a storage-array-like API
-- to be a free alternative to proprietary solutions, not to innovate.
OK, fair enough.
As far as a united rtslib is concerned, we need to make sure that it
supports targetd with minimal changes. Regarding locking, same thing as
above, we got into talking about two different things.
So all in all, let me quote Andy once more, as it sums up the situation
quite well: "There's work to be done but I can imagine worse starting
points."
Best Regards,
--
Jerome Martin
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
