[stgt] RFC, initial prototype to add add/delete/show portals to tgtadm/tgtd

[FUJITA Tomonori]

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
portal group.


> 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
> non-intuitive.
> 
> 
> Would you be ok with the syntax like this ?
> portal=<address>[:<port>][,<tpgt>]

I really want to avoid it, a separator character has two meanings. I
suspect that it will hurt us badly in the future.


> Example:
> --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
> otherwise.
> 
> But  lets do the portal groups/targets/...  things later once we have
> the ability to add / delete portals first.
> 
> 
> 
> 
> regards
> 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