public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Goldish <mgoldish@redhat.com>
To: Chen Cao <kcao@redhat.com>
Cc: autotest@test.kernel.org, kvm@vger.kernel.org
Subject: Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample
Date: Wed, 12 Aug 2009 07:29:25 -0400 (EDT)	[thread overview]
Message-ID: <545101808.1810391250076565847.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <241664321.1810221250076184432.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>


----- "Chen Cao" <kcao@redhat.com> wrote:

> On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > 
> > ----- "Chen Cao" <kcao@redhat.com> wrote:
> > 
> > > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > > > ---
> > > >  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?

The AutoIt test already sends the scripts to the guest at runtime.
Only the binaries need to be in an ISO.
The method of sending the scripts is slightly hackish (using echo),
but in my opinion it is robust and I don't expect it to cause any
trouble.

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

Everything you mentioned is already being done using rss.exe, except
for sending binaries to the guest.
The AutoIt test sends the script, launches it and queries the exit
status.
I can see why STAF is enough to control the tests, I just don't see how
it is better.

> Nevertheless, I'm eager to see the advanced rss.exe.
> 
> Thank you.
>  
> 
> Regards,
> 
> Cao, Chen
> 2009/08/12

       reply	other threads:[~2009-08-12 11:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <241664321.1810221250076184432.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-08-12 11:29 ` Michael Goldish [this message]
2009-08-13  1:18   ` [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample Cao, Chen
     [not found] <1448275709.1877381250155797510.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-08-13  9:30 ` Michael Goldish
     [not found] <27774843.1809421250070215580.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-08-12  9:44 ` Michael Goldish
2009-08-12 11:01   ` Cao, Chen
2009-08-11 12:10 [KVM-AUTOTEST PATCH v2 0/3] KVM test: corrections to the AutoIt patchset Michael Goldish
2009-08-11 12:10 ` [KVM-AUTOTEST PATCH v2 2/3] KVM test: add sample AutoIt script Michael Goldish
2009-08-11 12:10   ` [KVM-AUTOTEST PATCH v2 1/3] KVM test: add AutoIt test Michael Goldish
2009-08-11 12:10     ` [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample Michael Goldish
2009-08-12  2:05       ` Cao, Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545101808.1810391250076565847.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com \
    --to=mgoldish@redhat.com \
    --cc=autotest@test.kernel.org \
    --cc=kcao@redhat.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox