Hi All,
I disagree with dropping the stopper status for CR 7079889 due to the
following
reasons.
1) Any customers with an external FC device can not use it to install
the latest S11U1
and there is currently no work-around that we are aware of.
2) T5 and M4 product groups also consider this to be a product show stopper.
Please refer to Larry Wiebe's email on 2/17/2012 that Martin and Drew
were copied on
for details.
Thanks,
Son
On 4/12/2012 5:56 AM, Jesse Butler wrote:
On Apr 11, 2012, at 10:28 PM, Martin Widjaja wrote:
Jesse - Thanks for taking this up.
One question: any additional unit test or test case we need to introduce to
ensure this works fine? If it's a test case, might it be worth mentioning it to
QE so they can include this in their list?
I see Drew replied to this.
Other than that, LGTM!
Thanks!
BTW, for the other bug, 7079889, I was going to remove the potential stopper
status today but didn't get around to it. I will do this tomorrow and keep you
and Son in the loop.
I'm fine with dropping the stopper status if the SAN test team are. Last I
knew, they were not. From their perspective, it's definitely a stopper, as no
SPARC system can use an MP LUN for its installation. Note they are also fine
with the more complete solution of enabling MPxIO by default in Solaris on
SPARC, but that has yet to be fully vetted, let alone decided upon.
thanks
Jesse
Thanks,
Martin
On 4/11/2012 7:02 PM, Drew Fisher wrote:
LGTM!
Thanks for working on the fix to this!
-Drew
On 4/11/12 7:58 PM, Jesse Butler wrote:
Could I get a review for:
7150578 install discovery ignores device path lun numbers
This CR is a small piece of the overall multipath target selection issue that
the discovery code has. When we encounter multipath targets with MPxIO
disabled, as is the default on SPARC, everything kind of falls apart. This is
being worked separately.
During that work, this bug was discovered. For each drive we discover, we
retrieve a WWN. If the WWN name is found, we use it. We throw out subsequent
drives with the same WWN.
This is a problem in a few scenarios, most commonly when a RAID array is used.
Most RAID arrays use the WWN of the HBA and a LUN number to identify a LUN. So,
the current code will only discover one LUN per WWN, throwing away all the
other LUNs using the same WWN. This could be the entire array on some
configurations. Further, the ones that are put on the list are missing their
LUN number.
This changeset tacks the LUN number onto the end of the WWN string if it's in
use, thus getting around the bad duplication avoidance, and setting a full
WWN+LUN descriptor for each Disk object.
https://cr.opensolaris.org/action/browse/caiman/jesseb/7150578/webrev/
Thanks
Jesse
_______________________________________________
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
