resending to include the caiman-discuss alias

Paul Stanley - Sun Microsystems Ireland - Solaris Software wrote:
> angela wrote:
>   
>> Hi Paul,
>>
>> Good news, we find the issue that prevent us executing GUI test suite
>> instgui through remote ssh/rsh.
>> And we also setup a KVM, instgui got all PASS.
>>   
>>     
> That's great.
>   
>> The only issue is if execute the test again without reboot the system
>> and reset X, some test cases failed with error:
>>
>> 520|0 1 00001149 1 1|unexpected signal 11 (SIGSEGV) received.
>>
>> By tracing, we found most time the keyCombo() function call of dogtail
>> causes the error, but we do not know the further root cause.
>> We are also not sure that maybe other dogtail functions cause the same
>> issue.
>>
>> Fortunately we have the workaround that executing test suite after boot,
>> we suggest that we may go on PIT integration process.
>>   
>>     
> I think this should be okay - the reboot before starting can be handled
> by the STEP wrapper.
>   
>> The suggested solution is to use KVM over IP and execute testsuite:
>>
>> 1) Assume the system can be accessed by rsh/ssh before start to execute
>> test,
>> and the system should be set to boot from CD or USB automatically.
>>
>> 2) modify the opensolaris image to be tested:
>> - enable ssh or rsh service
>> Hope this can be done by ITeam.
>>   
>>     
> I'd suggest you log an RFE for this and we can mark it as a prerequisite
> for automated testing.
>   
>> 3) reboot SUT, so that SUT boot from LiveCD or LiveUSB
>>   
>>     
> Is this reboot not sufficient to avoid the issue you mentioned above?
>
> It's not clear how the test object gets onto the USB/CD. I would suggest
> this is also handled as part of the configuration in the STEP wrapper.
> Some people SST and PIT are also working on install type STEP testsuites
> (e.g. the S10 upgrade/liveupgrade tests) - maybe they can shed some
> light on how best to design testsuites that reinstall the system.
>   
>> 4) rsh/ssh to SUT with user "jack"
>>
>> 5) install packages needed
>>
>> 6) X-server and environment configuration
>> Xorg tcp_listen=true
>> export DISPLAY=:0.0
>> export LC_ALL=C
>> enable assitive technologies: AT-SPI
>> restart Xorg
>> xhost +
>>
>> 8) configure and execute test suite
>> execute test suite with jack user, using pfexec to get root permission.
>>
>> Do you have any concerns? Can this solution be possible for PIT environment?
>> If yes, we are planning to start STEP wrapping.
>>   
>>     
> Seems fine to me - I'm sure the others on the thread will join in if
> they have other issues or suggestions.
>
> Paul
>   
>> Cheers,
>> Angela
>>
>>
>> Paul Stanley - Sun Microsystems Ireland - Solaris Software ??:
>>   
>>     
>>> angela wrote:
>>>   
>>>     
>>>       
>>>> Hi Paul,
>>>>
>>>> 1) about KVM over IP solution:
>>>> We don't have this device right now, so at first, we connect the monitor
>>>> with SUT,
>>>> and tried to run test from remote system.
>>>> Unfortunately, we found there are some issues which prevent test
>>>> execution from remote system.
>>>>   
>>>>     
>>>>       
>>>>         
>>> Can you give some more details of the issues? This solution maps well to
>>> the current SST setup and has a couple of advantages when it comes to
>>> analysis.
>>>   
>>>     
>>>       
>>>> We suppose that with KVM or KVM over IP should act the same as with
>>>> monitor, right?
>>>> If so, then this solution will not work for this test suite.
>>>>
>>>> 2) about redirect to X server solution:
>>>> This can work, the X server can be any systems except SUT.
>>>> And the X server can run on snv, opensolaris or opensolaris microroot.
>>>>
>>>> So the following is one possible solution:
>>>>
>>>> 1) X-server configuration
>>>>
>>>> 2) modify SUNWgnome-gui-test which will be used by instgui:
>>>> Some codes in this package should be changed firstly, to disable dogtail
>>>> A11y checking.
>>>> This pkg will not be modified regularly, so we can do the modification
>>>> firstly,
>>>> and then install it to SUT when execute the test.
>>>>
>>>> 3) hack the opensolaris image to be tested:
>>>> - enable ssh or rsh service
>>>> Hope this can be done by ITeam.
>>>>   
>>>>     
>>>>       
>>>>         
>>> We should pass this as a testing requirement to the I-team - preferably
>>> a clean supported option to enable this.
>>>   
>>>     
>>>       
>>>> 3) boot the SUT from LiveCD or LiveUSB
>>>>
>>>> 4) rsh/ssh to SUT with user "jack"
>>>>
>>>> 5) su root
>>>> As opensolaris will not allow root login, so we must login with jack
>>>> firstly.
>>>> As new installer "gui-install" and test suite needs root permisstion to
>>>> execute.
>>>> So we are think using pfexec to workaround this.
>>>>   
>>>>     
>>>>       
>>>>         
>>> I don't see any reason this would not work
>>>   
>>>     
>>>       
>>>> Currently, we are not sure about this, we will try this after our
>>>> Chinese New Year holiday.
>>>> So if we could, then no need to su root.
>>>> While, if not, there are the following two solutions:
>>>> *) change the opensolaris image to allow root login
>>>> or
>>>> *) STEP should add support on this.
>>>>   
>>>>     
>>>>       
>>>>         
>>> If necessary this can be done I'm sure.
>>>   
>>>     
>>>       
>>>> 6) install packages needed
>>>>
>>>> 7) set DISPLAY and start /usr/lib/at-spi-registryd in background
>>>>
>>>> 8) configure and execute test suite
>>>>
>>>> So for us, we will go back to you on pfexec issue after holiday.
>>>>
>>>> Any comments?
>>>>
>>>> BTW, Jan.24 to Feb.1 2009 is our Chinese New Year holiday.
>>>> We will be back office at Feb.2.
>>>>
>>>> Have a nice week,
>>>> Angela
>>>>
>>>>
>>>> Paul Stanley - Sun Microsystems Ireland - Solaris Software ??:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> SST currently use a KVM over IP solution - the SUT thinks it has a
>>>>> monitor and if necessary (for analysis) an engineer can see what's being
>>>>> displayed. I can ask SST which exact models they use if you like.
>>>>>
>>>>> PIT don't have requirements for anything like this yet - but we could
>>>>> plan for this as part of install testing.
>>>>>
>>>>> There may be other solutions (depending on the X application) - e.g.
>>>>> just redirect the display to a single infrastructure server running an X
>>>>> server. In this scenario an engineers desktop could be passed as the
>>>>> target X server in cases where interaction is required - e.g. analysis
>>>>> of testcase fails
>>>>>
>>>>> There may be other solutions too.
>>>>>
>>>>> Paul
>>>>>
>>>>> angela wrote:
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>>> Hi Paul,
>>>>>>
>>>>>> I was unable to attend the last concall.
>>>>>> I would like to know how to run X application without monitor in PIT/SST?
>>>>>> Can you or someone give us an introduction firstly?
>>>>>>
>>>>>> Thanks,
>>>>>> Angela
>>>>>>
>>>>>>   
>>>>>>     
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>
>   


  • [caiman-discuss... Paul Stanley - Sun Microsystems Ireland - Solaris Software

Reply via email to