On 7/22/11 11:43 AM, Jesse Butler wrote:
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?
the from_xml() call in the Iscsi DOC class is called before discovery.py
ever runs and that's where we take care of the ip or lun not being supplied.
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 :)
Done.
# run devfsadm and wait for the iscsi devices to configure
run([DEVFSADM, "-i", "iscsi"])
Otherwise, TIFBMAYSPI!
:D
Thanks, Jesse!
-Drew
/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
