Re: plans for user-backed device support
by Andy Grover
On 02/04/2015 12:21 PM, Alex Elsayed wrote:
>> Maybe we step back and define a DBus interface
>
> I'd be quite happy with that - I considered suggesting it, in fact, but
> wasn't sure of the prevailing opinion re: dbus around here.
>
> What would you do re: discovery, though?
>
> (Explaining some DBus things, which readers may already be aware of)
>
> In DBus, there's a two-level hierarchy of busnames holding objects.
> Busnames are either the inherent, connection-level one of the :\d+.\d+ form,
> or the human-readable well-known name form (reverse DNS). Objects, then,
> implement interfaces.
>
> However, well-known names can only have a single owner - so discovering
> which busnames have objects which implement an interface is non-trivial.
>
> The approach taken by KDE is to suffix the well-known name with the PID
> (org.kde.StatusNotifierItem-2055 or whatever), call ListNames, and filter in
> the client. This has the drawback of making DBus activation impossible.
>
> Another approach is for every implementor to try to claim the well-known
> name, and on failure contact the existing owner to republish their objects
> (possibly under a namespaced object path). This has the drawback of
> complicating the implementation somewhat, as well as making bus activation
> only able to activate a single 'default' implementation.
>
> A third approach would be to explicitly define a multiplexor, which backends
> ask to republish their objects. This simplifies implementations, and it
> could also provide its own API that requests a backend by name, and ensures
> that backend's object is available. This could be driven by something as
> simple as a key-value mapping from backend name to a well-known DBus name
> specific to that backend, which the multiplexor calls to trigger service
> activation.
>
> Thoughts?
It really seems to come down to: will multiple independent user-handler
daemons be needed? Because I'm trying really hard to make tcmu-runner
good enough so that the answer is no :-)
tcmu-runner supports multiple handler modules, so it's extensible. It is
permissively licensed so no issues with non-FOSS handlers needing their
own daemon. It also could be replaced entirely (either with a modified
version of itself or from scratch) and still not give up the
single-busname, service activation approach.
So that would be my current preference. (The fact that the kernel API
doesn't preclude multiple handler daemons does not mean we need to
*support* those right away, or ever.)
If there are likely use cases that tcmu-runner is unsuitable for solving
by itself then that would change things of course, and let's please talk
about them!
-- Andy
8 years, 6 months
qla2xxx_npiv support
by Tomasz Charoński
Dear Andy Grover, targetcli-fb Developers,
firstly, I'd like to thank you for your contribution in targetcli and
related libraries developing. I am writing to you to ask, if there it is
possible to add to targetcli qla2xxx_npiv support. I have been studying
this for 2 days now and it's hard to create NPIV targets manually.
To create NPIV WWN using qla2xxx you need:
1. Create FC host using vport_create:
echo '1111222233334444:5555666677778888' >
/sys/class/fc_host/host5/vport_create
After this new /sys/class/fc_host/hostX will appear, but NPIV WWN is not
discovered at FC switch yet.
2. Create the path:
/sys/kernel/config/target/qla2xxx_npiv/21:00:00:xx:xx:xx:xx:11@5555666677778888:1111222233334444
where "21:00:00:xx:xx:xx:xx:11" is physical WWN taken from port_name
(sed needed).
3. qla2xxx_npiv directory seems to be the same as
/sys/kernel/config/target/qla2xxx. After enabling tgpt_1 I can see
"5555666677778888" at FC switch, however I can't successfuly share the
LUN with an initiator.
NPIV WWNs are needed to make user-friendly failover between hosts.
I am eager to help you in this development, especially including testing
this functionality in our infrastructure.
Best regards,
--
Tomasz Charoński
Storage Administrator
Ul. M. Palacza 113
60-273 Poznań
tel.: +48 61 859 70 07
fax: +48 61 623 25 79
www.beyond.pl <http://www.beyond.pl>
biuro(a)beyond.pl <mailto:biuro@beyond.pl>
NIP: 782-23-24-152
KRS: 0000237620
Sąd Rejonowy Poznań-Nowe Miasto i Wilda w Poznaniu
VIII Wydział Gospodarczy Krajowego Rejestru Sądowego
Kapitał Zakładowy: 2 539 700,00 PLN
UWAGA: Ta wiadomość oraz wszelkie załączniki są przeznaczone wyłącznie
dla adresata korespondencji e-mail. Jeśli otrzymałeś ten e-mail przez
pomyłkę, prosimy niezwłocznie powiadom nadawcę i usuń przesyłkę ze
swojego systemu wraz ze wszystkimi załącznikami. Kopiowanie,
dystrybucja, ujawnianie i inne wykorzystanie przesyłki e-mail, bez zgody
nadawcy, jest zakazane.
8 years, 11 months