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, 5 months
New releases: targetcli.fb41, rtslib.fb57, and configshell.fb18
by Andy Grover
Hi all,
Christophe has finished converting all three packages to use python-six
instead of 2to3, and some final fixes for Python 3. Great to see!
I would encourage everyone to use Py3 if possible. I would say Py3
should be considered the default, although Py2 is still supported, of
course.
Christophe's changes also include some configshell refactoring and
simplification.
Github:
https://github.com/agrover/targetcli-fb
https://github.com/agrover/rtslib-fb
https://github.com/agrover/configshell-fb
tarballs:
https://fedorahosted.org/released/targetcli-fb/
targetcli-fb 2.1.fb41:
Andy Grover <agrover(a)redhat.com> (2):
Ensure tag is valid when deleting a tpg
update version to 2.1.fb41
Christophe Vu-Brugier <cvubrugier(a)fastmail.fm> (4):
Support Python 3 with "six" instead of running `2to3`
Fix usage of an undefined variable caused by a typo
Fix bad indentation warnings reported by Pylint
Fix the "unused import" warnings reported by Pylint
rtslib-fb 2.1.fb57:
Andy Grover <agrover(a)redhat.com> (1):
update version to 2.1.fb57
Christophe Vu-Brugier <cvubrugier(a)fastmail.fm> (5):
Raise RTSLibNotInCFS when a storage object is not found in lookup
mode
Fix an undefined variable error caused by a typo
Replace the undefined ExecutionError exception with RTSLibError
Fix the "unused import" warnings reported by Pylint
Fix missing import of RTSLibBrokenLink
configshell-fb 1.1.fb18:
Andy Grover <agrover(a)redhat.com> (1):
update version to 1.1.fb18
Christophe Vu-Brugier <cvubrugier(a)fastmail.fm> (5):
Support Python 3 with "six" instead of running `2to3`
Fix integer divisions that are broken with Python 3
Fix the command line completion with Python 3
Remove the complete_key attribute from class ConfigShell
Simplify the _display_completions() method
Regards -- Andy
8 years, 9 months
qla2xxx target crashing with various kernels
by Tomasz Charoński
Hello,
I have a serious problem with crashing qla2xxx target. I have already
submitted the bug to Debian Kernel Team, however there is no response yet.
What I am using:
Debian 8.0
kernels: 3.16.0-4-amd64 (stable), 4.0.0-1 from sid (unstable)
targetcli 1:3.0~pre4.1~ga55d018-2, python-rtslib
1:3.0~pre4.1~g1b33ceb-2, python-rtslib-fb 2.1.45-4, python3-rtslib-fb
2.1.45-4, python-configshell 1.6.1~g020d540-2, python3-configshell-fb
1.1.fb17 from sid (unstable)
HBA FC Cards: 2 x QLogic QLE2672 (2-port 16G)
iblock specific options changed:
set attribute emulate_3pc=1
set attribute emulate_tpu=1
set attribute emulate_caw=1
It is for VAAI support. Also thin provisioning is working good with
those options enabled (unmap), but I haven't tested without them.
Currently we are using this target only with Windows + Veeam. When the
Veeam finishes a backup job, I think it calls sync, because IO size
increases to hundreds of MB (typically it's hundreds of kB); also
transfer speed increases for the moment. When the job is finished after
about half a minute the crash happens, however not always; rather after
a few days of working.
I tried to use both stable and unstable versions of kernels. The traces
after crash are different, but it still happens at the same moment. I am
attaching the traces from both kernels.
I am not sure if it's LIO/targetcli thing. If not, can you escalate the
case to QLogic developers, please?
If you need more information, do not hestitate to ask me. It is crucial
for me to make this target stable.
Best regards,
--
Tomasz Charoński
Storage Administrator
8 years, 9 months
ConfigShell: why does it do sorting of "completions" lists returned by ui_complete_* methods?
by Ryan Sawhill Aroha
I tried to pack the issue into the subject. Further explanation:
Imagine a ConfigNode class that has a ui_command_charges() method.
Imagine there's a corresponding ui_complete_charges() method with code
like this:
~~~
def ui_complete_charges(self, parameters, text, current_param):
if current_param == 'month':
L = map(str, range(-12, 13))
L.insert(0, '-24')
completions = [a for a in L
if a.startswith(text)]
else:
completions = []
return completions
~~~
So the goal here is to have tab-completion for this "month" option with
potential args starting at -24, followed by -12 to 12 (inclusive). I
mean, the numbers are in a list in that order, after all. Instead, the
following makes it clear that ConfigShell is doing some sorting on the
list my method generates:
~~~
/billing> charges month=
-1 -3 -9 2 8
-10 -4 0 3 9
-11 -5 1 4
-12 -6 10 5
-2 -7 11 6
-24 -8 12 7
....................................month
/billing> charges month=
~~~
For the record, this is just one example. I've noticed this multiple
times -- I'm curious to know if this is a bug or a feature. (Perhaps
simply a side-effect of implementation?)
I spent a little while looking at the completion code --
ConfigShell._complete_*() and ConfigShell._dispatch_completion(), AFAICT
-- but honestly ... it's above my pay grade right now. 10 minutes with
it was enough to make me want to subscribe and ask you all about this.
So ... bug? If not, I'd love any pointers on how I could change this
behavior on my own.
Thanks for reading.
8 years, 10 months