Hello Frank,
On 08/31/2016 10:46 PM, Frank Fegert wrote:
> On Tue, Aug 30, 2016 at 10:24:22PM +0200, Christian Seiler wrote:
>> Your fix is also correct, but I'm not sure I like the endless
>> list of -o -n repeats... I'll think about it for a while and if
>> I can't find a better solution, I'll commit your fix to git.
>> (And if I find a better solution, I'll commit that. ;-))
>
> By all means, please do! I'm also not particularly happy with this
> temporary fix, but "it did get the job done"[TM] ;-)
I haven't had time to test it yet (might even still have shell
syntax errors), but I've come up with the following:
get_lvm_vgs() {
# handle the case where we didn't get passed any PVs
# at all
[ $# -gt 0 ] || return
# subshell for pwd change
(
cd /dev
$PVS --noheadings -o vg_name "$@" 2>/dev/null
)
}
and later:
for _vg in $(get_lvm_vgs $iscsi_disks $iscsi_partitions $iscsi_multipath_disks
$iscsi_multipath_partitions) $LVMGROUPS ; do
Will do some tests in the next couple of days and upload a
fixed version.
>> Speaking of: you appear to be interested in a backport of
>> open-iscsi into Jessie because you want to use offloading via
>> iscsiuio. I've been thinking about uploading open-isns and
>> open-iscsi to jessie-backports myself (precisely to have iscsiuio
>> support available for Jessie users), but was unsure whether
>> there's enough people who'd be interested in that. Would that be
>> something you'd use yourself? Or would you want to continue to
>> use your special backported version instead? Since you're
>> actively using iscsiuio, I'd like to hear your opinion on that
>> first.
>
> No, i'd definitely prefer an "official" backported version of the
> package, provided it's based on reasonably recent open-iscsi upstream
> sources - there are several important fixes as of late not covered by
> the current Jessie package sources.
Ok, then I'll see to that. I'll have to talk to Ritesh (the other
co-maintainer of open-iscsi) first, and probably want to clarify
something with the backports ftp-masters, so it might take a couple
of weeks until it's in, but if you want, I can notify you via email
once I've created the corresponding packages, even if they are
stuck in the NEW queue for a while.
As for "recent-ness" of backports: the rules for jessie-backports
are that Stretch has to be tracked. Since open-iscsi with iscsiuio
will migrate to Stretch tomorrow (barring a last-minute RC bug),
that's going to be the lowest possible version that's going to
land in backports. And until Stretch is released, jessie-backports
would get all further improvements. (Though to be honest, I don't
see that many major changes happening until Stretch; iscsiuio and
the earlier rework of the startup logic were the big ones on my
list, and those are done.)
> I particularly like your idea of
> putting iscsiuio into its own package.
Yes. While it isn't harmful, I don't think having the daemon
started on every system, even those without bnx2 cards, is a
sensible default. ;-)
> What's a real pain though, is the whole hassle with "_netdev", "LVM-
> GROUPS",
So _netdev will need to stay, I don't see how to improve that. I do
want to get rid of LVMGROUPS in the long term (because I think that
is a layering violation), so in Stretch we'll recommend to use
lvmetad for activating LVM volumes (while still supporting the old
way until after the Stretch release). Doesn't help you for Jessie
though, because lvmetad is broken there. (And as far as I understood
it, the fix is too complicated to be pushed via a stable update.)
> and still having to tweak the multipath init script.
Could you be more specific here? What exactly do you need to do?
I still have an item on my TODO list to take a look at multipath
vs. iSCSI in Jessie (in Stretch it works), because there was a
bug report on debian-user about it - I just didn't manage to do
so yet. If you are using that and have already looked into it,
it would be great, then I could probably try to also get that
sorted. (No guarantees for 8.6 though, because that'll happen on
Sep. 17th, so the time window is a bit short there.)
> Compared to the straightforward
> use of targets through full iSOEs like e.g. the QME8262 cards, this
> just feels awkward. Maybe it's just me doing something terribly wrong
> ;-)
If you have specific suggestions for how things could be done
in a simpler manner, even if it's just documentation, then I'm
all ears. I do think it's the job of Debian packaging to provide
a good integration of software. But once you get to know a bit
of software very well, you don't necessarily see all the
usability issues, because you know how to do stuff. So if you
have any suggestions, just tell us.
Regards,
Christian
