Tomo, > 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. > Ok, not implementing any portal group is ok with me. And keeping everything as 'tgtd only supports one single portal group and that is #1' In that case, you really only ask for 'expand the portal structure to also keep a portal group tag but keep this hardcoded to 1' ? Please expand, I think I misunderstand you. regards ronnie sahlberg On Sun, Apr 17, 2011 at 5:02 PM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > 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
