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.
All I see are users. Maybe they have a commercial affiliation with Datera, RedHat or SuSe. Good. They still are users, and their value to me comes from the fact that they are probably using the software in the real-world.
OK fair enough :)
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.
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?
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. There's work to be done but I can imagine worse starting points.
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.
But yes, in other areas I agree the library is extremely important.
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.
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.
But this is still a lot of work. Maybe we should have a voice chat so that we can at least try to bind a little on a personal level and see if this can work? I'll send you my phone number privately, just give me a call so we can talk this out.
Sure, I'll email back about setting up a time. Regards -- Andy -- 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
