Question about tpg isolation

Question about tpg isolation

[Mark Syms]

Hi,

Got a possibly odd question. I'm pretty sure the iSCSI target doesn't
support this but wondered if it was something that could be considered
for future.

We've been trying to use the target to emulate a customer environment
that we do not have direct access to. They have a SAN which has a
fairly complex configuration. There are two array controllers, each
with its own IQN, each controller then has two TPGs each of which has
three portal addresses. So far this is all OK and we can emulate that
with a software target. Where it becomes difficult is when we look at
the responses from discovery. Each group of three portal addresses
will only return itself and the other two siblings, it will not return
the details of the portals on the other tpg or those for the other
array controller.

Our control plane software should work in this scenario but our
customer found a bug meaning it did not in all circumstances function
correctly. As part of producing a fix it would be preferable if we
could also create a regression test for this scenario to ensure that
after it is fixed it doesn't get broken again and without requiring
capital expense to purchase a representative SAN. Whilst the software
target can be configured with multiple IQNs and multiple tpgs and with
multiple portals for each tpg when performing discovery to any one of
those portals will respond with the details of all of the other
portals and thus will not trigger the bug that we have seen.

This is a little bit similar to
https://target-devel.vger.kernel.narkive.com/SyrmxKHS/lio-per-initiator-target-discovery-question,
but in our case we would be satisfying the ACL when contacting each of
the portal addresses so it's only the cross tpg discovery exposure
that we would want to disable.

Is this something that would be considered or is it just too specific
to a small use case?

Thanks,

Mark.