Just checking... in discovery.py, from line 694 onward, you don't need to verify that 'iscsi.target_ip' is not None, because the code in physical.py that parses it in has already done so, right?
Also in discovery.py, on line 722, you might want to use "devfsadm - i iscsi". Really up to you, but that will get you the desired "block until iSCSI devices settle" behavior without reconfiguring the entire tree. Since it's an installer kernel instance, probably not much of a diffference, either way... but, corner case - if you were installing to an iSCSI target on a head that was also attached to a few hundred Fibre Channel HDDs, it might take a while :) Otherwise, TIFBMAYSPI! /jb On Jul 22, 2011, at 12:42 PM, Drew Fisher wrote: > OK, round 3. > > https://cr.opensolaris.org/action/browse/caiman/drewfish/iscsi3/webrev/ > > I updated all the AI manifests to reflect the newest change. > > The biggest update for this round is in target.dtd. > > The entire IP element has been removed since it conflicted with the > source='dhcp' attribute for iscsi. I moved the IP address to be an attribute > of the <iscsi> element instead. > > Thanks! > > -Drew > > On 7/22/11 8:28 AM, Dermot McCluskey wrote: >> Drew, >> >> I agree with Darren's comment. DTD says: >> >> 141 If the source attribute is set to 'dhcp', we will use dhcp to >> 142 retrieve the Rootpath of the iSCSI boot parameters. No other >> 143 attributes should be specified. >> >> but DTD and code ensure that target_lun attrib >> must now always be specified. >> >> Also, do following files also need to be updated: >> ./cmd/auto-install/manifest/ai_manifest.xml: <iscsi name="c0d2E0001010F68"> >> ./cmd/auto-install/test/manifest_auto_reboot_not_set.xml: <iscsi >> name="c0d2E0001010F68"> >> ./cmd/auto-install/test/manifest_auto_reboot_false.xml: <iscsi >> name="c0d2E0001010F68"> >> ./cmd/auto-install/test/manifest_auto_reboot_true.xml: <iscsi >> name="c0d2E0001010F68"> >> ./cmd/auto-install/test/manifest_auto_reboot_invalid.xml: <iscsi >> name="c0d2E0001010F68"> >> >> >> - dermot >> >> >> On 07/22/11 15:09, Darren Kenny wrote: >>> I'm not sure that target_lun should be required in all cases - meaning that >>> I >>> don't think it should be required in the DTD, but should be semantically >>> validated in the code (e.g. from_xml() or TD). >>> >>> For example the commend says that if you have a source of 'dhcp' then don't >>> specify anything else - and I agree with the comment, but the DTD won't >>> allow it >>> now. >>> Best to do it in code... >>> >>> Other than that, all looking good. >>> >>> Thanks, >>> >>> Darren. >>> >>> On 21/07/2011 22:09, Drew Fisher wrote: >>>> Jesse and I worked on this some more after some feedback from Darren. >>>> >>>> I've spun a new webrev to address what Darren mentioned, in addition to >>>> concerns >>>> Jesse had. The biggest update is the target_lun is now marked #REQUIRED >>>> in the >>>> DTD file. This is to try to ensure the admin doesn't trash the same LUN >>>> across >>>> multiple initiators. >>>> >>>> Could I please get a couple of pairs of eyes on this? >>>> >>>> https://cr.opensolaris.org/action/browse/caiman/drewfish/iscsi2/webrev/ >>>> >>>> Thanks! >>>> >>>> -Drew >>>> >>>> On 7/20/11 4:42 PM, Drew Fisher wrote: >>>>> Good afternoon! >>>>> >>>>> Could I please get a code review for the following: >>>>> >>>>> 7068381<http://monaco.us.oracle.com/detail.jsf?cr=7068381> AI doesn't >>>>> retry >>>>> to list the iscsi target if the OS Device Name is not available >>>>> 7046878<http://monaco.us.oracle.com/detail.jsf?cr=7046878> iSCSI not >>>>> working >>>>> in targets code >>>>> >>>>> https://cr.opensolaris.org/action/browse/caiman/drewfish/iscsi/webrev/ >>>>> >>>>> >>>>> The problem with 7068381 is that we were not giving the system enough >>>>> time to >>>>> configure iscsi before proceeding to trying to list what the shares were. >>>>> The >>>>> fix here is to run devfsadm to wait for the devices to configure. >>>>> >>>>> >>>>> 7046878 is a much larger fix which required a minor change to the >>>>> target.dtd. >>>>> The change to the dtd allows the target_name to be optional (where it >>>>> used to >>>>> be required). This allows the user to specify something that looks like >>>>> this: >>>>> >>>>> <disk> >>>>> <iscsi> >>>>> <ip>10.83.220.100</ip> >>>>> </iscsi> >>>>> </disk> >>>>> >>>>> Which allows iscsi to use sendtargets (a sort of broadcast of all >>>>> available >>>>> shares) to tell the initiator which shares are available at that IP. >>>>> >>>>> We now have full LUN support as well. If an iscsi share has multiple LUNs >>>>> configured, the user will be required to specify which LUN they want to >>>>> use in >>>>> the manifest: >>>>> >>>>> <disk> >>>>> <iscsi target_lun="0"> >>>>> <ip>10.83.220.100</ip> >>>>> </iscsi> >>>>> </disk> >>>>> >>>>> If a share comes back with more than 1 LUN and the user does NOT specify >>>>> which >>>>> one they want, we raise an exception. We also raise an exception if the >>>>> LUN >>>>> number is invalid (e.g. the user specifies target_lun="5" and there's not >>>>> a >>>>> LUN #5 in the share). >>>>> >>>>> Static configurations are also fully supported and the user can specify >>>>> which >>>>> target_name they want: >>>>> >>>>> <disk> >>>>> <iscsi >>>>> target_name="iqn.1986-03.com.sun:02:659ae648-921a-43cf-a888-bb98a5d6a6b6" >>>>> target_lun="0"> >>>>> <ip>10.83.220.100</ip> >>>>> </iscsi> >>>>> </disk> >>>>> >>>>> >>>>> >>>>> If anybody has any questions or would like the x86 AI ISO I created to >>>>> play >>>>> around with, please let me know. >>>>> >>>>> Thanks! >>>>> >>>>> -Drew >>>>> >>>>> >>>>> _______________________________________________ >>>>> caiman-discuss mailing list >>>>> [email protected] >>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> [email protected] >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> _______________________________________________ >>> caiman-discuss mailing list >>> [email protected] >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
