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
>>>
>>>
>>>
>>
>>
>
>
