On 02/04/2015 09:50 AM, Alex Elsayed wrote:
>> Here's a proof-of-concept of what targetcli integration
might look like:
>>
https://github.com/agrover/targetcli-fb/tree/user-backstore-poc
>
> I have a couple questions about this.
>
> 1.) What about alternate frontend implementations that still want to use
> TCMU? By making the config module python, not only do you impose a presort
> on the implementations, you also likely have duplicated logic (the TCMU
> backend will need to validate parameters anyway, after all.)
>
> 2.) Why not have a dynbs_tcmu.py that talks to TCMU somehow, and have a
> few additional functions (explicit param validation, etc) added to the API
> that TCMU expects a backend to expose? That saves the backend implementer
> from having to care about rtslib's API; they just worry about the TCMU API
> they already were working with.
(Or heck, even a tiny python lib that dlopen's the handler_*.so and calls
the TCMU-defined API bits via FFI)
Very good points. So you're saying we don't want to tie the user-handler
discovery mechanism to our current configtool or its language.
It would also be nice to allow an alternate implementation of the TCMU
handler daemon, which dictates a degree of abstraction going the other
way. The current user-kernel interface is of course not dependent on
tcmu-runner, but also lets unrelated processes handle different sets of
user-backed backstores.
Maybe we step back and define a DBus interface that
$tcmu-handler-daemons would implement, which would allow $configtools to
enumerate handlers and pre-validate parameters. This would allow tight
integration of user-handled backstores in targetcli, but also keep
things loosely coupled enough to allow alternate implementations of
either side.
-- Andy