Angela, thank you very much for taking care of it.
Jan angela wrote: > jan damborsky ??: > >> Hi Angela, >> >> >> angela wrote: >> >> >>> jan damborsky ??: >>> >>> >>> >>>> Hi Angela, >>>> >>>> >>>> angela wrote: >>>> >>>> >>>> >>>> >>>>> Thanks Jan for detailed review. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> You are welcome :-) >>>> >>>> >>>> >>>> >>>> >>>>> According to your feedback, there are two aspects need to do: >>>>> 1. add sparc support >>>>> 2. modify zfs pool creation on slice device >>>>> >>>>> I would do aspect 2 firstly and then put back the testsuite into stc, >>>>> and then add sparc support. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> If you would agree, I might recommend to focus on support >>>> for Sparc first, since this is higher priority at time of being. >>>> We have been covering/testing x86 platform for a while, >>>> but as far as Sparc is concerned we stay at the beginning. >>>> >>>> As we did initial testing for Sparc, we don't expect to find >>>> serious issues modulo those already reported. However, >>>> more testing would need to be done in order to be sure >>>> we didn't neglect anything important. >>>> >>>> Thank you, >>>> Jan >>>> >>>> >>>> >>>> >>> Hi Jan, >>> >>> After discussed in our team, we decided to set the sparc support as high >>> priority; >>> and libti testsuite put back as low priority. >>> >>> To put back libti and integrate it into PIT, we need to go through a >>> process >>> which will take some times, so we'd like to begin it from now. >>> >>> >>> >> That sounds reasonable. >> >> >> >>> BTW, do you have any schedule on sparc support for TI module and test >>> driver? >>> We should make plan for libti testsuite sparc support. >>> >>> >>> >> Currently slim_source gate can be built on Sparc and both TI library (libti) >> as well as test driver (test_ti) can be used on Sparc and are assumed to be >> ready for testing. >> >> > Thanks, I'll try to build libti and test_ti, and get the support into > libti testsuite asap. > >> Thank you, >> Jan >> >> >> >> >>> Thanks, >>> Angela >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> Angela >>>>> >>>>> jan damborsky ??: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Angela, >>>>>> >>>>>> I have gone through the list of test assertions (attached for reference). >>>>>> They seem to cover the latest set of Target Instantiation features >>>>>> pretty well. I have only couple comments - please see below. >>>>>> >>>>>> I am also including William, who worked on libti support for >>>>>> Distro Constructor. >>>>>> >>>>>> As far as set of supported platforms is concerned, we have >>>>>> been focusing on x86 so far. Since we are now in process >>>>>> of enhancing the scope by taking Sparc platform into account, >>>>>> could I please ask you, if it might be possible to extend testing >>>>>> procedures, so that Sparc platform could be covered as well ? >>>>>> >>>>>> In general, libti is supposed to work across all Sparc architectures, >>>>>> but in near future 'sun4v' is prefered, so if you would like to limit >>>>>> the scope, please focus on 'sun4v' at time of being. >>>>>> >>>>>> As fdisk related test assertions are not applicable for Sparc, >>>>>> following test cases would be omitted: >>>>>> >>>>>> create_fdisk_001 >>>>>> create_fdisk_002 >>>>>> create_fdisk_003 >>>>>> >>>>>> With respect to the issues affecting support for Sparc we are currently >>>>>> aware of following problem: >>>>>> >>>>>> 3136 TI fails to create VTOC on unlabeled disk on Sparc >>>>>> >>>>>> If the unlabeled disk is attached to the SUT, it is necessary >>>>>> to create label on it (using format(1M)), otherwise libti would >>>>>> fail to create VTOC on that drive. >>>>>> >>>>>> Thank you very much, >>>>>> Jan >>>>>> >>>>>> >>>>>> create_vtoc_002 >>>>>> --------------- >>>>>> Since only SMI labeling is currently supported and utilized >>>>>> in the installer, this test case is assumed to work, but >>>>>> potential issues seen there would not be considered as libti >>>>>> bugs at time of being. >>>>>> >>>>>> >>>>>> create_rpool_004 >>>>>> create_rpool_001n >>>>>> create_be_001 >>>>>> create_be_001n >>>>>> create_fs_001 >>>>>> ----------------- >>>>>> Since creating ZFS pool on whole disk is unsupported >>>>>> and not currently utilized in the installer, could >>>>>> you please modify these test assertion, so that ZFS >>>>>> pool is created on slice instead ? >>>>>> >>>>>> >>>>>> create_volume_001 >>>>>> ----------------- >>>>>> # - ZFS root pool's name, $ZFS_RPOOL_NONEXIST, other than the >>>>>> # existing pool(s), check with 'zpool status'. >>>>>> -> >>>>>> # - name of existing ZFS root pool, $ZFS_RPOOL_NAME, check with >>>>>> # 'zpool status'. >>>>>> >>>>>> >>>>>> # - First, '$DRIVER_PATH/$DRIVER_NAME -c -t p -p $ZFS_RPOOL_NONEXIST' >>>>>> # - Second, '$DRIVER_PATH/$DRIVER_NAME -c -t l -p $ZFS_RPOOL_NONEXIST >>>>>> # -n $ZFS_VOLUME_NAME -z $ZFS_VOLUME_SIZE -u $ZFS_VOLUME_TYPE' >>>>>> -> >>>>>> # - First, '$DRIVER_PATH/$DRIVER_NAME -c -t p -p $ZFS_RPOOL_NAME >>>>>> # -d $SLICE_NAME' >>>>>> # - Second, '$DRIVER_PATH/$DRIVER_NAME -c -t l -p $ZFS_RPOOL_NAME >>>>>> # -n $ZFS_VOLUME_NAME -z $ZFS_VOLUME_SIZE -u $ZFS_VOLUME_TYPE' >>>>>> >>>>>> >>>>>> create_fs_001 >>>>>> ------------- >>>>>> # - ZFS root pool's name, $ZFS_RPOOL_NONEXIST, other than the >>>>>> # existing pool(s), check with 'zpool status'. >>>>>> -> >>>>>> # - name of existing ZFS root pool, $ZFS_RPOOL_NAME, check with >>>>>> # 'zpool status'. >>>>>> >>>>>> >>>>>> # - First, '$DRIVER_PATH/$DRIVER_NAME -c -t p -d $DISK_NAME >>>>>> # -p $ZFS_RPOOL_NONEXIST' >>>>>> # - Second, '$DRIVER_PATH/$DRIVER_NAME -c -t m -p $ZFS_RPOOL_NONEXIST >>>>>> # -n $ZFS_FS_NAME' >>>>>> -> >>>>>> # - First, '$DRIVER_PATH/$DRIVER_NAME -c -t p -d $SLICE_NAME >>>>>> # -p $ZFS_RPOOL_NAME' >>>>>> # - Second, '$DRIVER_PATH/$DRIVER_NAME -c -t m -p $ZFS_RPOOL_NAME >>>>>> # -n $ZFS_FS_NAME' >>>>>> >>>>>> >>>>>> release_zfspool_001 >>>>>> ------------------- >>>>>> # - '$DRIVER_PATH/$DRIVER_NAME -c -t p -p $ZFS_RPOOL_NAME -R' >>>>>> -> >>>>>> # - '$DRIVER_PATH/$DRIVER_NAME -c -t P -p $ZFS_RPOOL_NAME' >>>>>> >>>>>> >>>>>> release_zfspool_001n >>>>>> -------------------- >>>>>> # - '$DRIVER_PATH/$DRIVER_NAME -c -t p -p $ZFS_RPOOL_NONEXIST -R' >>>>>> -> >>>>>> # - '$DRIVER_PATH/$DRIVER_NAME -c -t P -p $ZFS_RPOOL_NONEXIST' >>>>>> >>>>>> >>>>>> angela wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, Jan. >>>>>>> >>>>>>> I attached the latest test assertion, please review. >>>>>>> >>>>>>> And also the workspace is at: >>>>>>> /net/rainday.prc/export/Projects/indiana/General/ws-snv-itc/src/suites/libti >>>>>>> >>>>>>> Cheers, >>>>>>> Angela >>>>>>> >>>>>>> jan damborsky ??: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Angela, >>>>>>>> >>>>>>>> only couple of things changed since last release - >>>>>>>> I think (I am not sure) that Hao did some changes >>>>>>>> in the testsuite to accommodate it. >>>>>>>> If you agree, I might take a look at latest list of test >>>>>>>> cases and I would get back to you with comments >>>>>>>> what should be changed or enhanced. >>>>>>>> Please let me know, what you think about this. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Jan >>>>>>>> >>>>>>>> >>>>>>>> angela wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Jan, >>>>>>>>> >>>>>>>>> This is Angela from Install Beijing QE team, I'm responsible for libti >>>>>>>>> testsuite now, replacing Wang Hao who has transferred to BSTE team. >>>>>>>>> >>>>>>>>> I heard that you wrote libti test driver, so I wonder does there any >>>>>>>>> modification on it, since last release? >>>>>>>>> And does there any new features on libti? If yes, I will enhance >>>>>>>>> libti testsuite accordingly. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Angela >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
