>>> Mike Christie <[email protected]> schrieb am 24.02.2011 um 06:05 in
Nachricht <[email protected]>:

[...]

I still have some questions (see inline comments).

> I am not sure you guys are talking about the same issue. Here is the 
> long story for why we have discoverydb and discover mode. It is 
> bascially because I messed up. So if you like long stories read on. If 
> not skip to the patch comments :)
> 
> 
> In the discoverydb issue it is that with discoverydb mode you can use -o 
> new to create a discovery record manually. This was to make it easier to 
> script/manage. So if you had multiple discovery addresses that needed 
> different discovery settings you had to edit iscsid.conf discovery 
> settings, run iscsiadm discovery command for -p A, then edit iscsid.conf 
> disocvery settings again and then rerun iscsiadm discovery command for -p B.
> 
> With discoverydb mode your script can do
> 
> iscsiadm -m discoverydb -p ip:port -o new
> iscsiadm -m discoverydb -p ip:port -o update -n discovery.somesetting -v 
> value
> iscsiadm -m discoverdb -p ip:port -D
> 
> 
> A long time ago, I think when Alex and Dimitry and I transitioned 
> maintainership, I messed up the original "discovery" mode. We used to do 
> something like the above with -o new in the old discovery mode and 
> --login in discovery mode had you use the discovery record and login to 
> the discovery address. But at some point I changed it so -o new operated 
> on the node records that got created and --login logged into the portals 
> that got discovered.
> 
> A couple months ago I realized I messed up when someone was requesting 
> the behavior. I could not change the current discovery behavior because 
> users were using it so I added the discoverydb mode which acts on the 
> discovery db. (I think no one noticed I messed up before because there 
> not as many users or at least we did not have vocal users because no one 
> said anything. And I never knew I messed up until I was looking at that 
> code a couple months ago).
> 
> So now we have commands like:
> 
> // just create discovery record

If not there already? Is  this mode dependent on the actual exstence of the 
portal, or does it allow to "pre-create" a record for a portal to be used later?

> iscsiadm -m discoverydb -p ip:port -o new
> you can then use -o update to edit the settings like in node mode.
> 
> 
> // do discovery and only add records for portals that are not yet 
> present in the db
> iscsiadm -m discovery -p ip:port -o new
> or
> iscsiadm -m discoverydb -p ip:port --discover -o new
> // note that for discoverydb mode you pass in the --discover argument, 
> and that the discoverydb command will use the discovery record settings 
> where discovery mode would use the iscsid.conf settings.
> 

What is unclear: In which of the commands above I can specify variable settings 
different from iscsid.conf (so that those are recorded permanently with the 
corresponding DB records)?

> 
> 
> 
> >
> > And found it pretty awkward to use; after all, to all intents and
> > purposes the hostname and the IP-address can be used interchangeably.
> > I (and our QA :-( ) don't see a reason why should draw a blank here.
> >
> 
> I just added support for this to node mode with commit 
> 4d045cdeaf701f8abe6bee4f1e433f7bc9c50493.
> 
> I did not add support for discovery mode, because I figured you would 
> just use whatever you used the first time. With node mode though the 
> target decided and you had no control. I am ok with adding support though.
> 
> 
> > So after long hours of debugging I came up with this patch, which
> > resolves the hostname into the IP address and uses this for lookup.
> >
> 
> I am ok with the idea. I am not sure if the patch works ok though. I was 
> not sure what version to apply it to, so the comment below are based on 
> me trying to port it.
> 
> For the patch it seems if you passed in a hostname into
> 
> iscsiadm -m discovery -p myhost -t st
> 
> but later did
> 
> iscsiadm -m discovery -p myhost
> 
> it would not work since we are only resolving in the discovery path. So 
> we need to resolve and convert in other paths. For example if you ran
> 
> iscsiadm -m discovery
> or
> iscsiadm -m discovery -P 1
> 
> you get the ip address printed out when if they passed in the hostname 
> they probably want to see the hostname.
> 
> Also it seems since we resolve the hostname to a IP and use that for 
> discovery record value if the hostname changes IPs then the db is messed up.
> 
> For 4d045cdeaf701f8abe6bee4f1e433f7bc9c50493 I tried to do the 
> resolution on the fly. So the user/target gives us whatever they want 
> then I tried to resolve and match. I will try to convert your patch to 
> support the above. Give me a couple days. I am very backed up (I am just 
> about done porting the broadcom patch to fix if 
> session_login_task->iscsi_conn_connect->ep_connect fails with a 
> transient error).

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to