Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> 
> ----- "Chen Cao" <kcao@xxxxxxxxxx> wrote:
> 
> > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > Signed-off-by: Michael Goldish <mgoldish@xxxxxxxxxx>
> > > ---
> > >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> > >  1 files changed, 11 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > b/client/tests/kvm/kvm_tests.cfg.sample
> > > index 12e907b..05a1ca7 100644
> > > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > > @@ -126,6 +126,16 @@ variants:
> > >          kill_vm_gracefully = no
> > >          extra_params += " -snapshot"
> > >  
> > > +    - autoit:       install setup
> > > +        type = autoit
> > > +        cdrom = windows/autoit.iso
> > I am wondering what is the advantage of using .iso to store the
> > binary
> > files. I think it might be hard to maintain the (scripts/binary)
> > files.
> > is it possible to pass a directory to run_autoit()?
> 
> - I don't think it's too much trouble to maintain one big ISO that
>   will serve all Windows tests.  I think we should start documenting
>   its contents in the wiki.
>   (Currently, by default, each test that requires a binary uses a
>   different ISO file (rss.iso, vlc.iso, autoit.iso) but I think it's
>   a good idea to put everything in a single ISO.)
> 
if the autoit scripts are changed, the iso has to be updated everytime
before testing, have you already got a good solution for this?

> - qemu doesn't directly read from directories, as far as I know.
>   It requires an image file (ISO).
> 
> - We currently don't support sending files to all Windows guests.
>   (We have no solution for Vista and 2008, which are quite important,
>   and the solution I'm currently aiming for is adding send/receive
>   functionality to rss.exe.)
> 
> > > +        autoit_binary = D:\AutoIt3.exe
> > > +        autoit_script_timeout = 600
> > > +        autoit_script_params =
> > > +        variants:
> > > +            - notepad:
> > > +                autoit_script = autoit/notepad1.au3
> > > +... blahblah...
> > 
> > Besides, I think we may use staf framework to send command to MS
> > Windows
> > to run autoit scripts, it would be easier to control the status of
> > the
> > autoit process.
> 
> What advantages does STAF have?  I don't think we lack control over the
> AutoIt process, especially since by default, rss.exe kills all processes
> (AutoIt in this case) started by a session when that session exits.
> This can also be done manually, in case rss.exe isn't used, but I left
> that to a future patch.
> 
> STAF is non-interactive, which means working with it will be different
> from working with SSH, Telnet or rss.exe.  Do you suggest that we use
> STAF for everything, or just for the AutoIt tests?
> Using it for everything means we wouldn't have shell interactivity;
> using it for AutoIt makes sense only if STAF is really that much better
> for AutoIt tests than regular interactive shells.
> 
I meant STAF for AutoIt only.
An advanced rss.exe may be the ultimate solution for MS Windows,
and life would be much easier.

but before that, we may also use some other tools to send file to guests,
and STAF to control the autoit tests. we just need to launch the test
and query the status, STAF is enough.

Nevertheless, I'm eager to see the advanced rss.exe.

Thank you.
 

Regards,

Cao, Chen
2009/08/12

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux