<div dir="ltr"><div>Hi Christian</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 24, 2020 at 1:51 PM Christian Ehrhardt <<a href="mailto:christian.ehrhardt@canonical.com">christian.ehrhardt@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 3:23 AM Rafael David Tinoco <<a href="mailto:rafaeldtinoco@ubuntu.com" target="_blank">rafaeldtinoco@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I have always used TGT project, despite its bad performance, as iSCSI<br>
target in Linux, offering iSCSI luns for HA clusters. It was known to me<br>
that TGT was *not* the best iSCSI target supported in Linux, being LIO<br>
the chosen project for that (now called TCM:<br>
<a href="https://www.kernel.org/doc/Documentation/target/tcmu-design.txt" rel="noreferrer" target="_blank">https://www.kernel.org/doc/Documentation/target/tcmu-design.txt</a>).<br>
<br>
In a recent need, I needed SCSI 3 reservations in those SCSI volumes, to<br>
test and enable fence_scsi agent, and was getting unclear errors when<br>
trying to reserve the LUNs.<br>
<br>
The following commands - that would register a reservation key, reserve<br>
a lun, release the reservation and unregister the key - don't work when<br>
using TGT iSCSI luns with open-scsi and iscsid tool/service.<br>
<br>
$ sg_persist -r /dev/sda<br>
$ sg_persist --out --register --param-sark=123abc /dev/sda<br>
$ sg_persist --out --reserve --param-rk=123abc --prout-type=5 /dev/sda<br>
<br>
prout-type = 5 -> executes SCSI PERSISTENT RESERVE OUT (5Fh) command<br>
with the PREEMPT AND ABORT (05h) service<br>
<br>
(<a href="https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1863688" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1863688</a>)<br>
<br>
$ sg_persist --out --release --param-rk=123abc --prout-type=5 /dev/sda<br>
$ sg_persist --out --register --param-rk=123abc /dev/sda<br>
<br>
With that, its impossible to fence iSCSI luns using corosync/pacemaker<br>
clusters.<br>
<br>
TCM (or LIO) project fully supports fencing and several other iSCSI<br>
features. It also supports userland backends that can extend backing<br>
devices so it supports: qcow2, ceph, etc...<br>
<br>
Despite being HA only or not, this use case is actually being used in<br>
this email to show the need to have a tool that configures kernel TCM<br>
(or LIO) capability as a supported tool (at least IMO).<br>
<br>
I have found a recent previous MIR attempt of 1/3 of what is needed:<br>
<br>
<a href="https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1854362" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1854362</a><br>
<br>
But, afaict, we would need MIRs for:<br>
<br>
- python3-configshell-fb<br>
- python3-rtslib-fb<br>
- targetcli-fb<br>
<br>
To have the "targetcli" tool in [main]. Upstream projects are hosted<br>
together with open-iscsi repository, suggesting that they are actively<br>
maintained and in good shape.<br>
<br>
Has this ever been discussed ? It looks to me something we could/should<br>
have in 20.04. Thoughts ?<br></blockquote><div> </div><div>IIRC <span style="color:rgb(0,0,0);font-family:monospace">cinder-volume was the last bit holding back a switch.</span></div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">$ reverse-depends -r focal tgt
</span><br>Reverse-Depends
<br>===============
<br>* cinder-volume
<br>* tgt-rbd [amd64 arm64 armhf ppc64el s390x]<br>
<br></span></div><div><span style="font-family:monospace">And at least cinder-volume is in main.</span></div><div><span style="font-family:monospace">So we'd have to have that changed to make the switch (as we should have only one supported iSCSI in main).</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">IIRC that was also the reason we waited on last time and checking the bug [1] confirms similar thoughts.</span></div><div><span style="font-family:monospace">It seems you are working with jamespage already to make that switch happen.</span></div></div></div></blockquote><div><br></div><div>I have a branch prepared for cinder to switch over the default iSCSI target helper to LIO.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Also security needs to process all the extra packages in just three days - unlikely right?</div><div><br></div><div>IMHO while I agree It would be nice for 20.04 but if it is not doable in time due to all these constraints it is ok as well to "just" target 20.10 with it.</div><div>Please be on the same page with <a class="gmail_plusreply" id="gmail-m_6913498617900047094plusReplyChip-0" href="mailto:josh.powers@canonical.com" target="_blank">@Josh Powers</a> on this as this will be quite an intense ride to be squeezed into 20.04.</div><div><br></div><div>P.S. FYI another reason in the past was maas but they are in a snap now and use their "own" tgt, so no dependency to consider anymore.</div><div>P.P.S. have you asked (TBH I'd not know where) if some of our primary charms might depend on tgt?</div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">[1]: </span><a href="https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1854362/comments/17" target="_blank">https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1854362/comments/17</a></div><div><span style="font-family:monospace"><br></span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks!<br>
<br>
Rafael<br>
<br>
-- <br>
ubuntu-server mailing list<br>
<a href="mailto:ubuntu-server@lists.ubuntu.com" target="_blank">ubuntu-server@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-server" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-server</a><br>
More info: <a href="https://wiki.ubuntu.com/ServerTeam" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/ServerTeam</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Christian Ehrhardt<br>Staff Engineer, Ubuntu Server<br>Canonical Ltd</div></div>
-- <br>
ubuntu-server mailing list<br>
<a href="mailto:ubuntu-server@lists.ubuntu.com" target="_blank">ubuntu-server@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-server" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-server</a><br>
More info: <a href="https://wiki.ubuntu.com/ServerTeam" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/ServerTeam</a></blockquote></div></div>