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

[ronnie sahlberg]

On Sun, Apr 17, 2011 at 10:59 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sun, 17 Apr 2011 10:24:01 +1000
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> This would allow to add and remove portals from tgtd at runtime
>> without the need for shutting down and restarting tgtd any time
>> the portal configuration changes.
>
> Sounds good.
>
>
>> To operate on portals, I added a new mode to tgtadm/tgt :
>>
>> Example use:
>>
>> $ sudo ./usr/tgtadm --lld iscsi --op show --mode portal
>> Portal: 0.0.0.0:3260
>> Portal: [0::0]:3260
>
> Can we handle portal group? tgt doesn't support it but the interface
> needs to handle it, I think.

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.

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>]

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
* 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