search

open-iscsi / targetcli-fb

Command shell for managing Linux LIO kernel target
Apache License 2.0
103 stars 69 forks source link

Provide user backend registration #73

Open famz opened 8 years ago

famz commented 8 years ago

The TCM-Userspace (TCMU) handler types are currently only queried from tcmu-runner's DBus service. While the latter has recently introduced a proxy protocol for other handler processes to register themselves so they can be used in targetcli (see tcmulib_register() in libtcmu library), the drawback of this indirection layer is that it makes tcmu-runner service an extra dependency of other handlers.

If we can add a daemon process in targetd that publishes a handler registration service by itself (via DBus or other measures), the custom handler process can then work independently from tcmu-runner daemon.

@agrover @pkalever @vbellur Let's use this issue to explore this idea and if we can reach a consensus, I'll look into sending a PR.

agrover commented 8 years ago

Exchange tcmu-runner dependency for a targetd dependency? targetd has more dependencies, more RAM-intensive (written in Python), I'm not sure why moving tcmu-runner functionality into targetd would be a good thing to do. I mean, tcmu-runner is serving as a proxy. Is there any way to get targetcli talking to the multiple, independent handler providers directly?

famz commented 8 years ago

Sorry for the confusion, I wasn't talking about the targetd, it was a typo and s/targetd/target system service/. Let me try again.

So my intent is exactly "get targetcli talking to the multiple, independent handler providers directly". To do that I can think of two possibilities:

  1. targetcli centralized. We implement a daemon subcommand in targetcli and change the target.service type from oneshot to dbus and own a bus name org.$whatever.TargetcliManage1, both tcmu-runner and other handlers can talk to it. We need to think about how to persistent the handlers information across target service restarts, because users are accustomed to use "systemctl restart target" to reload targetcli config.
  2. decentralized services. All handlers own a bus named with a well known prefix, like org.$whatever.TCMUHandler- and generate unique postfixes e.g. org.$whatever.TCMUHandler-$0-$$ (process name plus pid). This way, a handler doesn't depend on target service to run to fully function, and no worry about persistent across restartings of target service.