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
--
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
