[stgt] RFC, initial prototype to add add/delete/show portals to tgtadm/tgtd
fujita.tomonori at lab.ntt.co.jp
Sun Apr 17 09:02:59 CEST 2011
On Sun, 17 Apr 2011 16:10:32 +1000
ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
> Ok. I can add setting a portal group tag for each portal, and have it
> default to ptgt 1
> by default.
> That would need some additional changes in the discovery and login
> processing, but that should not be too painful.
Please simply reject if users specify a portal group that isn't
one. tgt doesn't support portal group now so no point to point non 1
> The biggest question would be of the syntax and how to specify it.
> The most natural way to specify the tpgt would be using ',<tpgt>'
> Like :
> tgtd --iscsi portal=10.1.1.27:3260,1
> But ',' is already taken for specifying
> --iscsi portal=10.1.1.27:3260,portal=10.1.1.28:3261
> or if other iscsi parameters will be added later.
> I like being able to specify multiple comma-separated portals using
> ike that, and also comma-separated other arguments that may be added
> in the future.
> But I would also like to retain using ',<tpgt>' since that seems to be
> the de-facto way to show / describe target portal group tags.
> Picking a different character as the tpgt would solve the issue but be
> Would you be ok with the syntax like this ?
I really want to avoid it, a separator character has two meanings. I
suspect that it will hurt us badly in the future.
> --iscsi portal=10.1.1.27:3260
> --iscsi portal=10.1.1.27:3260,2
> --iscsi portal=10.1.1.27:3260,2,portal=1.1.27:3262,3
> --iscsi portal=10.1.1.27:3260,portal=1.1.27:3262,3
> In this case ',' is sometimes a argument separator and sometimes a
> tpgt separator.
> Not optimal but I could live with this syntax.
> Are you ok with this syntax or would you prefer a different syntax?
> > And how can we see the binding of a target and portals
> I would like to do that part later, once the add/remove portals is
> finished and merged first.
> But with TPGT support I could imagine it could be something like
> * each target is assigned to one single tpgt
Why? Even if I don't have any plan to add such feature, I think that
we need to add the interface capable of it.
> * default is that a target is bound to tgpt:1 but a new tgtadm
> command could be used to change it
> * discovery and login support are enhanced to only allow and filter
> based on the tpgt bound to that target.
> * discovery checks the portal that the discovery session is bound to
> and uses this to find which tpgt this portal belongs to
> this is used to filter the list of returned targets.
> I.e. if you connected to a portal in tpgt:5 you will only discover
> targets that belong to that same tpgt. Other targets on other portal
> groups are not shown.
> * During login, find which portal group the session connected to and
> verify that the requested target belongs to that group. Fail the login
> But lets do the portal groups/targets/... things later once we have
> the ability to add / delete portals first.
> ronnie sahlberg
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt