On Sun, 17 Apr 2011 16:10:32 +1000 ronnie sahlberg <ronniesahlberg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
