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

2009-08-11 Thread Cao, Chen 
On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> Signed-off-by: Michael Goldish 
> ---
>  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()?

> +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 is your suggestion?

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2009-08-12 Thread Cao, Chen 
On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> 
> - "Chen Cao"  wrote:
> 
> > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > Signed-off-by: Michael Goldish 
> > > ---
> > >  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2009-08-12 Thread Cao, Chen 
On Wed, Aug 12, 2009 at 07:29:25AM -0400, Michael Goldish wrote:
> 
> - "Chen Cao"  wrote:
> 
> > On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > > 
> > > - "Chen Cao"  wrote:
> > > 
> > > > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > > > Signed-off-by: Michael Goldish 
> > > > > ---
> > > > >  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.

it seems that this testcase cannot handle more one one .au3 files.
and i think it quite possible that there are testcases that require
two or more .au3 files, for reusing code or some other reasons.

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

[KVM-AUTOTEST PATCH] KVM test: kvm_tests: fix a litte bug in timedrift()

2009-08-28 Thread Cao, Chen 
the original version compared a wrong drift value with given threshold.

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_tests.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/client/tests/kvm/kvm_tests.py b/client/tests/kvm/kvm_tests.py
index b100269..4e3391e 100644
--- a/client/tests/kvm/kvm_tests.py
+++ b/client/tests/kvm/kvm_tests.py
@@ -773,7 +773,7 @@ def run_timedrift(test, params, env):
 # Fail the test if necessary
 if drift > drift_threshold:
 raise error.TestFail("Time drift too large: %.2f%%" % drift)
-if drift > drift_threshold_after_rest:
+if drift_total > drift_threshold_after_rest:
 raise error.TestFail("Time drift too large after rest period: %.2f%%"
  % drift_total)
 
-- 
1.6.0.6

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

[KVM-AUTOTEST PATCH 1/2] Adding Cerberus Test Control System 2 (ctcs2) as client test

2009-09-18 Thread Cao, Chen 
- Using a newer version compared to the existed cerberus test.
- User can specifiy cerberus testcases by providing command line
options in control file.
- Added a patch to fix the makefile to make cerberus run on
x86_64 system.

NOTE: this test may need a longer autotest timeout than the default one.

Signed-off-by: Cao, Chen 
---
 client/tests/cerberus2/0001-fix-ctcs2-build.patch  |  174 +++
 client/tests/cerberus2/0002-compile-on-64bit.patch |  175 
 client/tests/cerberus2/cerberus2.py|  107 
 client/tests/cerberus2/control |   21 +++
 client/tests/kvm/kvm_tests.cfg.sample  |3 +
 5 files changed, 480 insertions(+), 0 deletions(-)
 create mode 100644 client/tests/cerberus2/0001-fix-ctcs2-build.patch
 create mode 100644 client/tests/cerberus2/0002-compile-on-64bit.patch
 create mode 100644 client/tests/cerberus2/cerberus2.py
 create mode 100644 client/tests/cerberus2/control

diff --git a/client/tests/cerberus2/0001-fix-ctcs2-build.patch 
b/client/tests/cerberus2/0001-fix-ctcs2-build.patch
new file mode 100644
index 000..acf1566
--- /dev/null
+++ b/client/tests/cerberus2/0001-fix-ctcs2-build.patch
@@ -0,0 +1,174 @@
+diff --git a/runin/src/chartst.c b/runin/src/chartst.c
+index 4a20b38..63b1a5a 100644
+--- a/runin/src/chartst.c
 b/runin/src/chartst.c
+@@ -9,6 +9,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ void handler(int i) {
+   exit (0);
+diff --git a/runin/src/memtst.src/maxalloc.c b/runin/src/memtst.src/maxalloc.c
+index 5c48356..4863791 100755
+--- a/runin/src/memtst.src/maxalloc.c
 b/runin/src/memtst.src/maxalloc.c
+@@ -10,9 +10,6 @@
+ 
+ #if defined(__BSD__)
+   static const size_t PAGE_SIZE = 4096;
+-#else
+-/* this is horribly architecture specific */
+-  #include 
+ #endif
+ 
+ 
+diff --git a/runin/src/memtst.src/memtst.c b/runin/src/memtst.src/memtst.c
+index f086f28..538f770 100755
+--- a/runin/src/memtst.src/memtst.c
 b/runin/src/memtst.src/memtst.c
+@@ -10,8 +10,6 @@
+ 
+ #if defined(__BSD__)
+   static const size_t PAGE_SIZE = 4096;
+-#else
+-  #include 
+ #endif
+ 
+ /* The verbose global from memtst_main.c */
+@@ -331,6 +329,12 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+   int kmem_file;
+   int d;
+ 
++  /* Newer linux distributions don't have asm/page.h therefore
++   * we are going to get the page size using the value of
++   * _SC_PAGESIZE instead.
++   */
++  u_long page_size = sysconf(_SC_PAGESIZE);
++
+   /* window manipulation, iterator, read retval, etc */
+   int low, high, foo;
+   int rd;
+@@ -353,7 +357,7 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+ 
+   /* Now compute the offset (in chars) of the error from the page
+  boundary. */
+-  fail_page_offset = ((int) (&nbuf[offset])) % PAGE_SIZE;
++  fail_page_offset = ((int) (&nbuf[offset])) % page_size;
+ 
+   kmem_file = open("/proc/kcore",0);
+   if (kmem_file < 0) {
+@@ -370,7 +374,7 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+* window.
+*/
+   fail_page_offset -= ((offset - low) * sizeof(int));
+-  if (fail_page_offset < 0) fail_page_offset+=PAGE_SIZE;
++  if (fail_page_offset < 0) fail_page_offset+=page_size;
+ 
+   printf("%d %x fail_page_offset\n",fail_page_offset,fail_page_offset);
+ 
+@@ -382,8 +386,8 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+*/ #include 
+  #include 
+ 
+-  lseek(kmem_file,pages*PAGE_SIZE+fail_page_offset,SEEK_SET);
+-  phys_addr=pages*PAGE_SIZE+fail_page_offset;
++  lseek(kmem_file,pages*page_size+fail_page_offset,SEEK_SET);
++  phys_addr=pages*page_size+fail_page_offset;
+ 
+   /* We now use lseeks to (hugely) improve the performance of this
+  thing.  Large memory systems were extremely painful before. 
+@@ -396,8 +400,8 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+   foo = low;  
+   /* Every time we miss, skip to the next page. */
+   ++pages;
+-  
lseek(kmem_file,pages*PAGE_SIZE+fail_page_offset,SEEK_SET);
+-  phys_addr=pages*PAGE_SIZE+fail_page_offset;
++  
lseek(kmem_file,pages*page_size+fail_page_offset,SEEK_SET);
++  phys_addr=pages*page_size+fail_page_offset;
+   continue;
+   }
+   /* If foo made it to high, we've found it. */
+@@ -410,7 +414,7 @@ void kmemscan (int *nbuf, int block_size, int offset) {
+   fprintf(stderr, "Possible location of memory failure: 
%p (%dM) on page %d\n",
+   (void *) failure,
+   (int) (failure/1024/1024),
+-  (int) (failure/PAGE_SIZE));

[KVM-AUTOTEST PATCH] Adding NAS Parallel Benchmarks(NPB) as client test [1/2]

2009-09-21 Thread Cao, Chen 
- Using NPB OpenMP implementaion.

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_tests.cfg.sample   |4 +
 client/tests/npb/control|   28 
 client/tests/npb/enable-all-tests.patch |  233 +++
 client/tests/npb/npb.py |   95 +
 4 files changed, 360 insertions(+), 0 deletions(-)
 create mode 100644 client/tests/npb/control
 create mode 100644 client/tests/npb/enable-all-tests.patch
 create mode 100644 client/tests/npb/npb.py

diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 285a38f..0b2ab37 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -90,6 +90,10 @@ variants:
 - disktest:
 test_name = disktest
 test_control_file = disktest.control
+- npb:
+test_name = npb
+test_control_file = npb.control
+extra_params += " -smp 2"
 
 - linux_s3: install setup
 type = linux_s3
diff --git a/client/tests/npb/control b/client/tests/npb/control
new file mode 100644
index 000..d6c2adb
--- /dev/null
+++ b/client/tests/npb/control
@@ -0,0 +1,28 @@
+NAME = "NAS Parallel Benchmarks"
+AUTHOR = "Cao, Chen "
+TEST_TYPE = "CLIENT"
+TEST_CLASS = "HARDWARE"
+TEST_CATEGORY = "BENCHMARK"
+TIME = "MEDIUM"
+DOC = """\
+Using NPB, OpenMP implementation.
+
+See http://www.nas.nasa.gov/Software/NPB/
+"""
+
+# Supported tests (benchmarks):
+#   bt.A bt.B bt.C bt.D bt.E bt.S bt.W
+#   cg.A cg.B cg.C cg.S cg.W
+#   dc.A dc.B dc.S dc.W
+#   ep.A ep.B ep.C ep.D ep.E ep.S ep.W
+#   ft.A ft.B ft.S ft.W
+#   is.A is.B is.C is.S is.W
+#   lu.A lu.B lu.C lu.S lu.W
+#   mg.A mg.B mg.S mg.W
+#   sp.A sp.B sp.C sp.D sp.E sp.S sp.W
+#   ua.A ua.B ua.C ua.S ua.W
+#
+# Please refer to npb.py for more infomation about
+# the arguments.
+job.run_test(url='npb', tests='ep.A ep.B', ratio=0.5)
+
diff --git a/client/tests/npb/enable-all-tests.patch 
b/client/tests/npb/enable-all-tests.patch
new file mode 100644
index 000..f08a9d3
--- /dev/null
+++ b/client/tests/npb/enable-all-tests.patch
@@ -0,0 +1,233 @@
+diff --git a/NPB3.3-OMP/config/make.def b/NPB3.3-OMP/config/make.def
+new file mode 100644
+index 000..afffe7d
+--- /dev/null
 b/NPB3.3-OMP/config/make.def
+@@ -0,0 +1,161 @@
++#---
++#
++#SITE- AND/OR PLATFORM-SPECIFIC DEFINITIONS. 
++#
++#---
++
++#---
++# Items in this file will need to be changed for each platform.
++#---
++
++#---
++# Parallel Fortran:
++#
++# For CG, EP, FT, MG, LU, SP, BT and UA, which are in Fortran, the following 
++# must be defined:
++#
++# F77- Fortran compiler
++# FFLAGS - Fortran compilation arguments
++# F_INC  - any -I arguments required for compiling Fortran 
++# FLINK  - Fortran linker
++# FLINKFLAGS - Fortran linker arguments
++# F_LIB  - any -L and -l arguments required for linking Fortran 
++# 
++# compilations are done with $(F77) $(F_INC) $(FFLAGS) or
++#$(F77) $(FFLAGS)
++# linking is done with   $(FLINK) $(F_LIB) $(FLINKFLAGS)
++#---
++
++#---
++# This is the fortran compiler used for Fortran programs
++#---
++F77 = gfortran
++# This links fortran programs; usually the same as ${F77}
++FLINK = $(F77)
++
++#---
++# These macros are passed to the linker 
++#---
++F_LIB  =
++
++#---
++# These macros are passed to the compiler 
++#---
++F_INC =
++
++#---
++# Global *compile time* flags for Fortran programs
++#---
++FFLAGS= -O -fopenmp 
++
++#---
++# Global *link time* flags. Flags for increasing maximum executable 
++# size usually go here. 
++#---
++FLINKFLAGS = -O -fopenmp 
++
++
++#

[PATCH] Adding NAS Parallel Benchmarks(NPB) as client test [1/2] V2

2009-09-21 Thread Cao, Chen 
- Using NPB OpenMP implementaion.

Changes from the original patch:
Remove the variant 'extra_params += smp 2', and add a restriction
(no autotest.npb) under variant 'up', according to mgoldish's advice.
Nevertheless, user can run this test with smp=1, if he/she wants to.

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_tests.cfg.sample   |4 +
 client/tests/npb/control|   28 
 client/tests/npb/enable-all-tests.patch |  233 +++
 client/tests/npb/npb.py |   95 +
 4 files changed, 360 insertions(+), 0 deletions(-)
 create mode 100644 client/tests/npb/control
 create mode 100644 client/tests/npb/enable-all-tests.patch
 create mode 100644 client/tests/npb/npb.py

diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 285a38f..b03b7cd 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -90,6 +90,9 @@ variants:
 - disktest:
 test_name = disktest
 test_control_file = disktest.control
+- npb:
+test_name = npb
+test_control_file = npb.control
 
 - linux_s3: install setup
 type = linux_s3
@@ -567,6 +570,7 @@ linux_s3:
 
 variants:
 - @up:
+no autotest.npb
 - smp2:
 extra_params += " -smp 2"
 
diff --git a/client/tests/npb/control b/client/tests/npb/control
new file mode 100644
index 000..d6c2adb
--- /dev/null
+++ b/client/tests/npb/control
@@ -0,0 +1,28 @@
+NAME = "NAS Parallel Benchmarks"
+AUTHOR = "Cao, Chen "
+TEST_TYPE = "CLIENT"
+TEST_CLASS = "HARDWARE"
+TEST_CATEGORY = "BENCHMARK"
+TIME = "MEDIUM"
+DOC = """\
+Using NPB, OpenMP implementation.
+
+See http://www.nas.nasa.gov/Software/NPB/
+"""
+
+# Supported tests (benchmarks):
+#   bt.A bt.B bt.C bt.D bt.E bt.S bt.W
+#   cg.A cg.B cg.C cg.S cg.W
+#   dc.A dc.B dc.S dc.W
+#   ep.A ep.B ep.C ep.D ep.E ep.S ep.W
+#   ft.A ft.B ft.S ft.W
+#   is.A is.B is.C is.S is.W
+#   lu.A lu.B lu.C lu.S lu.W
+#   mg.A mg.B mg.S mg.W
+#   sp.A sp.B sp.C sp.D sp.E sp.S sp.W
+#   ua.A ua.B ua.C ua.S ua.W
+#
+# Please refer to npb.py for more infomation about
+# the arguments.
+job.run_test(url='npb', tests='ep.A ep.B', ratio=0.5)
+
diff --git a/client/tests/npb/enable-all-tests.patch 
b/client/tests/npb/enable-all-tests.patch
new file mode 100644
index 000..f08a9d3
--- /dev/null
+++ b/client/tests/npb/enable-all-tests.patch
@@ -0,0 +1,233 @@
+diff --git a/NPB3.3-OMP/config/make.def b/NPB3.3-OMP/config/make.def
+new file mode 100644
+index 000..afffe7d
+--- /dev/null
 b/NPB3.3-OMP/config/make.def
+@@ -0,0 +1,161 @@
++#---
++#
++#SITE- AND/OR PLATFORM-SPECIFIC DEFINITIONS. 
++#
++#---
++
++#---
++# Items in this file will need to be changed for each platform.
++#---
++
++#---
++# Parallel Fortran:
++#
++# For CG, EP, FT, MG, LU, SP, BT and UA, which are in Fortran, the following 
++# must be defined:
++#
++# F77- Fortran compiler
++# FFLAGS - Fortran compilation arguments
++# F_INC  - any -I arguments required for compiling Fortran 
++# FLINK  - Fortran linker
++# FLINKFLAGS - Fortran linker arguments
++# F_LIB  - any -L and -l arguments required for linking Fortran 
++# 
++# compilations are done with $(F77) $(F_INC) $(FFLAGS) or
++#$(F77) $(FFLAGS)
++# linking is done with   $(FLINK) $(F_LIB) $(FLINKFLAGS)
++#---
++
++#---
++# This is the fortran compiler used for Fortran programs
++#---
++F77 = gfortran
++# This links fortran programs; usually the same as ${F77}
++FLINK = $(F77)
++
++#---
++# These macros are passed to the linker 
++#---
++F_LIB  =
++
++#---
++# These macros are passed to the compiler 
++#---
++F_INC =
++
++#---
++# Global *comp

Re: [KVM-AUTOTEST,01/17] Add new module kvm_subprocess

2009-10-12 Thread Cao, Chen 

Hi, Michael,

I found that if the sessions initialized using kvm_subprcoess are not closed,
the processes will never exit, and /tmp/kvm_spawn will be filled with the
temporary files.

And we can find in the code,
# kvm_subprocess.py
...
# Read from child and write to files/pipes
while True:
check_termination = False
# Make a list of reader pipes whose buffers are not empty
fds = [fd for (i, fd) in enumerate(reader_fds) if buffers[i]]
# Wait until there's something to do
r, w, x = select.select([shell_fd, inpipe_fd], fds, [], 0.5)
# If a reader pipe is ready for writing --
for (i, fd) in enumerate(reader_fds):
if fd in w:
bytes_written = os.write(fd, buffers[i])
buffers[i] = buffers[i][bytes_written:]
# If there's data to read from the child process --
if shell_fd in r:
try:
data = os.read(shell_fd, 16384)
except OSError:
data = ""
if not data:
check_termination = True
# Remove carriage returns from the data -- they often cause
# trouble and are normally not needed
data = data.replace("\r", "")
output_file.write(data)
output_file.flush()
for i in range(len(readers)):
buffers[i] += data
# If os.read() raised an exception or there was nothing to read --
if check_termination or shell_fd not in r:
pid, status = os.waitpid(shell_pid, os.WNOHANG)
if pid:
status = os.WEXITSTATUS(status)
break
# If there's data to read from the client --
if inpipe_fd in r:
data = os.read(inpipe_fd, 1024)
os.write(shell_fd, data)
...

that if session.close() is not called, we will loop in the 'while' forever.

So, user have to make sure that unnecessary sessions are all killed,
otherwise, running some testcase(s) for huge number of times will suck
out all the system resource, which I think is very inconvenient.
Especially when we have to take care of many exceptions that may be raised
by our program.

e.g.

...
session = kvm_test_utils.wait_for_login(vm)
...
session2 = kvm_test_utils.wait_for_login(vm_x)
...
try:
...
except ...:
...
...
(other code may raise exceptions)
...
try:
...
except ...:
...
...
try:
...
except ...:
...
...

cleaning up the sessions will be exhausting here.

Do we have a good (or better) way to handle this?
Thanks.


Regards,

Cao, Chen
2009-10-12

On Mon, Jul 20, 2009 at 12:07 PM, Michael Goldish
wrote:
> This module is intended to be used for controlling all child
> processes in KVM
> tests: both QEMU processes and SSH/SCP/Telnet processes. Processes
> started with
> this module keep running and can be interacted with even after the
> parent
> process exits.
>
> The current run_bg() utility tracks a child process as long as the
> parent
> process is running. When the parent process exits, the tracking
> thread
> terminates and cannot resume when needed.
>
> Currently SSH/SCP/Telnet communication is handled by
> kvm_utils.kvm_spawn, which
> does not allow the child process to run after the parent process
> exits. Thus,
> open SSH/SCP/Telnet sessions cannot be reused by tests following the
> one in
> which they are opened.
>
> The new module provides a solution to these two problems, and also
> saves some
> code by reusing common code required both for QEMU processes and
> SSH/SCP/Telnet
> processes.
>
> Signed-off-by: Michael Goldish 
> ---
>  client/tests/kvm/kvm_subprocess.py | 1146
>  
>  1 files changed, 1146 insertions(+), 0 deletions(-)
>  create mode 100644 client/tests/kvm/kvm_subprocess.py
>

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

Re: [KVM-AUTOTEST,01/17] Add new module kvm_subprocess

2009-10-12 Thread Cao, Chen 
On Mon, Oct 12, 2009 at 09:07:45AM -0400, Michael Goldish wrote:
> You're right, currently the sessions must be closed explicitly.
> This is due to the fact that both qemu and ssh/telnet are handled by the
> same code, and qemu has to keep running in the background if we want to
> pass it from one test to another.
> 
> To deal with this, first, we should use try..finally blocks to close all
> sessions in tests.  As far as I know all existing tests (or at least most
> of them) already do this.
> 
> Second, we can add a destructor function to kvm_shell_session that will
> close the session automatically when it's no longer referenced.  At the
> moment this won't work because there's a thread running in the background
> tracking output from the session, but this thread is usually not needed
> for ssh/telnet (it's needed mainly for qemu), so we can selectively get
> rid of it and allow the reference count to drop to zero when the test exits,
> thus allowing the destructor to be called.
> 
> I'll think of a way to do the second thing, and if it works, maybe we won't
> need the first.  But for now every test should close its sessions explicitly.
> 
> BTW, I'm not sure I understand why cleaning up the sessions should be
> exhausting in the case you presented.  You can just wrap everything in one
> big try..finally block:
> 
> session = ...
> 
> try:
>   try:
>   except:
>   try:
>   except:
>   ...
> finally:
>   session.close()
> 

Thanks for your explanation.

It is just boring and error-prone to add lots of
'(dst|src|tmp|etc)*sesson.close()' to our code (the internal version)
into different files and big number of functions. and some of the
'sessions' are in the try...except blocks, and some are not.

We have to make sure where we started the sessions and to close all of
them when they are not needed any longer. I feel it's a little weird
that we have to do the garbage-collection-like work while using python.

so, since this is a known issue, or precisely, limitation of 'ease of
use', I'm looking forward to your impovement, and I think, we will
also try to work it out at the same time.

Thanks again for your help.


Cao, Chen
2009-10-13

> - Original Message -
> From: "Chen Cao" 
> To: "Michael Goldish" 
> Cc: autot...@test.kernel.org, kvm@vger.kernel.org
> Sent: Monday, October 12, 2009 8:55:59 AM (GMT+0200) Auto-Detected
> Subject: Re: [KVM-AUTOTEST,01/17] Add new module kvm_subprocess
> 
> 
> Hi, Michael,
> 
> I found that if the sessions initialized using kvm_subprcoess are not closed,
> the processes will never exit, and /tmp/kvm_spawn will be filled with the
> temporary files.
> 
> And we can find in the code,
> # kvm_subprocess.py
> ...
> # Read from child and write to files/pipes
> while True:
> check_termination = False
> # Make a list of reader pipes whose buffers are not empty
> fds = [fd for (i, fd) in enumerate(reader_fds) if buffers[i]]
> # Wait until there's something to do
> r, w, x = select.select([shell_fd, inpipe_fd], fds, [], 0.5)
> # If a reader pipe is ready for writing --
> for (i, fd) in enumerate(reader_fds):
> if fd in w:
> bytes_written = os.write(fd, buffers[i])
> buffers[i] = buffers[i][bytes_written:]
> # If there's data to read from the child process --
> if shell_fd in r:
> try:
> data = os.read(shell_fd, 16384)
> except OSError:
> data = ""
> if not data:
> check_termination = True
> # Remove carriage returns from the data -- they often cause
> # trouble and are normally not needed
> data = data.replace("\r", "")
> output_file.write(data)
> output_file.flush()
> for i in range(len(readers)):
> buffers[i] += data
> # If os.read() raised an exception or there was nothing to read --
> if check_termination or shell_fd not in r:
> pid, status = os.waitpid(shell_pid, os.WNOHANG)
> if pid:
> status = os.WEXITSTATUS(status)
> break
> # If there's data to read from the client --
> if inpipe_fd in r:
> data = os.read(inpipe_fd, 1024)
> os.write(shell_fd, data)
> ...
> 
> that if session.close() is not called, we wil

[PATCH] Using shutil.move to move result files in job.py

2009-10-12 Thread Cao, Chen 
Since os.rename requires that the file is in the same partition with
the dest directory, we would get a python OSError if the result
directory is mounted to a nfs server (or different partition or
something else alike).

the traceback would be like:

  Traceback (most recent call last):
File "/usr/local/kvm/kvm-test/bin/autotest", line 52, in ?
  options.log)
File "/usr/local/kvm/kvm-test/bin/job.py", line 1274, in runjob
  myjob.complete(0)
File "/usr/local/kvm/kvm-test/bin/job.py", line 798, in complete
os.rename(self.state_file, dest)
  OSError: [Errno 18] Invalid cross-device link

Signed-off-by: Cao, Chen 
---
 client/bin/job.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/client/bin/job.py b/client/bin/job.py
index a1c07cc..ebfb3a3 100755
--- a/client/bin/job.py
+++ b/client/bin/job.py
@@ -938,7 +938,7 @@ class base_job(object):
 """Clean up and exit"""
 # We are about to exit 'complete' so clean up the control file.
 dest = os.path.join(self.resultdir, os.path.basename(self.state_file))
-os.rename(self.state_file, dest)
+shutil.move(self.state_file, dest)
 
 self.harness.run_complete()
 self.disable_external_logging()
-- 
1.6.0.6

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

[PATCH] KVM Test: Add re.IGNORECASE to re.compile to verify_ip_address_ in kvm_utils.py

2009-10-26 Thread Cao, Chen 
Since the mac address is (changed to) lowercase and the output of
'arping' is in uppercase, we need re.IGNORECASE in the re.compile.

(the re.IGNORECASE in the re.search function takes no effect on the
compiled regex.)

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_utils.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index f72984a..934f223 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -190,7 +190,7 @@ def verify_ip_address_ownership(ip, macs, timeout=10.0):
 # Compile a regex that matches the given IP address and any of the given
 # MAC addresses
 mac_regex = "|".join("(%s)" % mac for mac in macs)
-regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex))
+regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex), re.IGNORECASE)
 
 # Check the ARP cache
 o = commands.getoutput("/sbin/arp -n")
-- 
1.6.0.6

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

Re: [PATCH] KVM Test: Add re.IGNORECASE to re.compile to verify_ip_address_ in kvm_utils.py

2009-10-28 Thread Cao, Chen 
On Wed, Oct 28, 2009 at 03:20:41AM -0400, Michael Goldish wrote:
> Thanks for catching this.
> While we're at it, why not remove the 2 occurrences of re.IGNORECASE
> that have no effect?

I just chose to ignore the code that does not break the tests.

I'd like to send a patch to remove the 2 're.IGNORECASE's and
use regex.search(o), as you recommended, to let Lucas to decide
the perferred way to fix. :-)

Thanks for your advice.

Cao, Chen
2009/10/28

> We can also replace re.search(regex, o) with the slightly shorter
> regex.search(o), but that's just a cosmetic change.
> 



> - Original Message -
> From: "Chen Cao" 
> To: l...@redhat.com, autot...@test.kernel.org
> Cc: kvm@vger.kernel.org, "Chen Cao" 
> Sent: Tuesday, October 27, 2009 6:03:36 AM (GMT+0200) Auto-Detected
> Subject: [PATCH] KVM Test: Add re.IGNORECASE to re.compile to 
> verify_ip_address_ in kvm_utils.py
> 
> Since the mac address is (changed to) lowercase and the output of
> 'arping' is in uppercase, we need re.IGNORECASE in the re.compile.
> 
> (the re.IGNORECASE in the re.search function takes no effect on the
> compiled regex.)
> 
> Signed-off-by: Cao, Chen 
> ---
>  client/tests/kvm/kvm_utils.py |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
> index f72984a..934f223 100644
> --- a/client/tests/kvm/kvm_utils.py
> +++ b/client/tests/kvm/kvm_utils.py
> @@ -190,7 +190,7 @@ def verify_ip_address_ownership(ip, macs, timeout=10.0):
>  # Compile a regex that matches the given IP address and any of the given
>  # MAC addresses
>  mac_regex = "|".join("(%s)" % mac for mac in macs)
> -regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex))
> +regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex), re.IGNORECASE)
>  
>  # Check the ARP cache
>  o = commands.getoutput("/sbin/arp -n")
> -- 
> 1.6.0.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[KVM-Autotest Patch] KVM Test: Add re.IGNORECASE to re.compile to verify_ip_address_ in kvm_utils.py - v2

2009-10-28 Thread Cao, Chen 
Since the mac address is (changed to) lowercase and the output of
'arping' is in uppercase, we need re.IGNORECASE in the re.compile.

And substitute re.search(regex, 0, ...) with regex.search(o), as
Michael Goldish (mgold...@redhat.com) suggested.

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_utils.py |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/client/tests/kvm/kvm_utils.py b/client/tests/kvm/kvm_utils.py
index f72984a..b9219f6 100644
--- a/client/tests/kvm/kvm_utils.py
+++ b/client/tests/kvm/kvm_utils.py
@@ -190,11 +190,11 @@ def verify_ip_address_ownership(ip, macs, timeout=10.0):
 # Compile a regex that matches the given IP address and any of the given
 # MAC addresses
 mac_regex = "|".join("(%s)" % mac for mac in macs)
-regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex))
+regex = re.compile(r"\b%s\b.*\b(%s)\b" % (ip, mac_regex), re.IGNORECASE)
 
 # Check the ARP cache
 o = commands.getoutput("/sbin/arp -n")
-if re.search(regex, o, re.IGNORECASE):
+if regex.search(o):
 return True
 
 # Get the name of the bridge device for arping
@@ -206,7 +206,7 @@ def verify_ip_address_ownership(ip, macs, timeout=10.0):
 
 # Send an ARP request
 o = commands.getoutput("/sbin/arping -f -c 3 -I %s %s" % (dev, ip))
-return bool(re.search(regex, o, re.IGNORECASE))
+return bool(regex.search(o))
 
 
 # Functions for working with the environment (a dict-like object)
-- 
1.6.0.6

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

[PATCH] Increase waiting time before first session check in kvm_test_utils.reboot

2009-11-25 Thread Cao, Chen 
Increase the sleeping time before the first check to 10 seconds,
and try every 2 seconds.

But increasing these values cannot really solve the following problem:
Guest is too heavy loaded, and have no time to response the
rebooting (method=shell) request, so session.is_responsive returns
False, and we pass the first 'kvm_utils.wait_for';
  a WHILE later the load becomes lighter, and sshd (or rss) become
responsive, whether or not is guest rebooting, here we are trying
to establish a session to the guest at this point, unfortunately,
we succeed and pass the second 'wait_for', before rebooting kills
sshd (or rss).

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_test_utils.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/client/tests/kvm/kvm_test_utils.py 
b/client/tests/kvm/kvm_test_utils.py
index bf8aed2..e183dc6 100644
--- a/client/tests/kvm/kvm_test_utils.py
+++ b/client/tests/kvm/kvm_test_utils.py
@@ -91,7 +91,7 @@ def reboot(vm, session, method="shell", 
sleep_before_reset=10, nic_index=0,
 logging.error("Unknown reboot method: %s" % method)
 
 # Wait for the session to become unresponsive and close it
-if not kvm_utils.wait_for(lambda: not session.is_responsive(), 120, 0, 1):
+if not kvm_utils.wait_for(lambda: not session.is_responsive(), 120, 10, 2):
 raise error.TestFail("Guest refuses to go down")
 session.close()
 
-- 
1.5.5.6

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

Re: [PATCH] Increase waiting time before first session check in kvm_test_utils.reboot

2009-11-25 Thread Cao, Chen 
On Thu, Nov 26, 2009 at 02:08:23AM -0500, Michael Goldish wrote:
> 
> - "Chen Cao"  wrote:
> 
> > Increase the sleeping time before the first check to 10 seconds,
> > and try every 2 seconds.
> > 
> > But increasing these values cannot really solve the following
> > problem:
> > Guest is too heavy loaded, and have no time to response the
> > rebooting (method=shell) request, so session.is_responsive
> > returns
> > False, and we pass the first 'kvm_utils.wait_for';
> >   a WHILE later the load becomes lighter, and sshd (or rss)
> > becomes
> > responsive, whether or not is guest rebooting, here we are trying
> > to establish a session to the guest at this point, unfortunately,
> > we succeed and pass the second 'wait_for', before rebooting kills
> > sshd (or rss).
> > 
> > Signed-off-by: Cao, Chen 
> > ---
> >  client/tests/kvm/kvm_test_utils.py |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/client/tests/kvm/kvm_test_utils.py
> > b/client/tests/kvm/kvm_test_utils.py
> > index bf8aed2..e183dc6 100644
> > --- a/client/tests/kvm/kvm_test_utils.py
> > +++ b/client/tests/kvm/kvm_test_utils.py
> > @@ -91,7 +91,7 @@ def reboot(vm, session, method="shell",
> > sleep_before_reset=10, nic_index=0,
> >  logging.error("Unknown reboot method: %s" % method)
> >  
> >  # Wait for the session to become unresponsive and close it
> > -if not kvm_utils.wait_for(lambda: not session.is_responsive(),
> > 120, 0, 1):
> > +if not kvm_utils.wait_for(lambda: not session.is_responsive(),
> > 120, 10, 2):
> 
> By default, is_responsive() waits 5 secs before deciding the session
> is unresponsive.  You can change that line to:
> 
> if not kvm_utils.wait_for(lambda: not session.is_responsive(timeout=20),
> 
> to give the session 20 secs to respond before it's deemed unresponsive.
> You can also make it 30.  Will that be long enough?
> 

I think this helps, thanks.

> BTW, I'm just curious -- what load is running on the guest?

e.g.
adding benchmarks of network/floating point/others as background
workload while doing live migrations.

use autoit to launch testing tools in Windows guests.

> Why would you want to reboot while the guest is loaded?
> 

to check if blue-screen happens when rebooting after the tests in
(Windows) guest, for example.

> >          raise error.TestFail("Guest refuses to go down")
> >  session.close()
> >  
> > -- 
> > 1.5.5.6
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Cao, Chen

GnuPG Key-ID:AC54E05E
keyserver hkp://keys.gnupg.net
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[KVM-AUTOTEST PATCH] Improve kvm subtest AutoIt - add option to download script from remote server

2009-11-30 Thread Cao, Chen 
Add an option to let user download the .au3 script from a remote
server, and keep the original method to prepare the script.

This makes it possible to employ AutoIt tests that involve several
files.

new variants:
1. download,
   if params.get("download") == "yes", download the scripts to guest,
   else use the original method, echo the code into guest.
2. download_cmd,
   What tool to use to download.
   User can choose git, as in the sample file, svn, ftp, or wget,
   or other preferred tools.
   NOTE, this requires that the download tool is installed in the
   guest, or the tools have been placed in winutils.iso.
3. rsc_server,
   Resource server which contains the AutoIt script
   and provide a download service.
4. dst_rsc_dir,
   Destination of the AutoIt scripts in the guest.
   i.e. the downloaded resource will be saved in this default dir.
5. autoit_entry,
   Which .au3 file to start to run.
   this will be useful if a test involves several .au3 files.

Signed-off-by: Cao, Chen 
---
 client/tests/kvm/kvm_tests.cfg.sample |6 
 client/tests/kvm/tests/autoit.py  |   45 ++--
 2 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 5e15b30..f688b97 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -169,6 +169,12 @@ variants:
 variants:
 - notepad:
 autoit_script = autoit/notepad1.au3
+- stub:
+download = yes
+download_cmd = "git clone"
+rsc_server = "git://the.resource.server/autoit"
+dst_rsc_dir = "C:\"
+autoit_entry = "C:\autoit\stub\stub.au3"
 
 - guest_s4: install setup unattended_install
 type = guest_s4
diff --git a/client/tests/kvm/tests/autoit.py b/client/tests/kvm/tests/autoit.py
index 9435d7c..ed1d491 100644
--- a/client/tests/kvm/tests/autoit.py
+++ b/client/tests/kvm/tests/autoit.py
@@ -25,23 +25,40 @@ def run_autoit(test, params, env):
 # Collect test parameters
 binary = params.get("autoit_binary")
 script = params.get("autoit_script")
+autoit_entry = params.get("autoit_entry", "script.au3")
 script_params = params.get("autoit_script_params", "")
 timeout = float(params.get("autoit_script_timeout", 600))
 
-# Send AutoIt script to guest (this code will be replaced once we
-# support sending files to Windows guests)
-session.get_command_output("del script.au3", internal_timeout=0)
-file = open(kvm_utils.get_path(test.bindir, script))
-for line in file.readlines():
-# Insert a '^' before each character
-line = "".join("^" + c for c in line.rstrip())
-if line:
-# Append line to the file
-session.get_command_output("echo %s>>script.au3" % line,
-   internal_timeout=0)
-file.close()
-
-command = "cmd /c %s script.au3 %s" % (binary, script_params)
+# Download the script resource from a remote server, or
+# prepare the script using rss?
+if params.get("download") == "yes":
+download_cmd = params.get("download_cmd")
+rsc_server = params.get("rsc_server")
+dst_rsc_dir = params.get("dst_rsc_dir")
+
+# Change dir to dst_rsc_dir, and remove 'autoit' there, then
+# download the resource.
+rsc_cmd = "cd %s && (rmdir /s /q autoit || del /s /q autoit) && " \
+  "%s %s" % (dst_rsc_dir, download_cmd, rsc_server)
+
+if session.get_command_status(rsc_cmd, timeout=timeout) != 0:
+raise error.TestFail("Download test resource failed.")
+logging.info("Download resource finished.")
+else:
+# Send AutoIt script to guest (this code will be replaced once we
+# support sending files to Windows guests)
+session.get_command_output("del script.au3", internal_timeout=0)
+file = open(kvm_utils.get_path(test.bindir, script))
+for line in file.readlines():
+# Insert a '^' before each character
+line = "".join("^" + c for c in line.rstrip())
+if line:
+# Append line to the file
+session.get_command_output("echo %s>>script.au3" % line,
+   internal_timeout=0)
+file.close()
+

Re: [KVM-AUTOTEST PATCH] Improve kvm subtest AutoIt - add option to download script from remote server

2009-12-01 Thread Cao, Chen 
On Tue, Dec 01, 2009 at 02:49:43AM -0500, Michael Goldish wrote:
> 
> - "Chen Cao"  wrote:
> 
> > Add an option to let user download the .au3 script from a remote
> > server, and keep the original method to prepare the script.
> > 
> > This makes it possible to employ AutoIt tests that involve several
> > files.
> > 
> > new variants:
> > 1. download,
> >if params.get("download") == "yes", download the scripts to guest,
> >else use the original method, echo the code into guest.
> > 2. download_cmd,
> >What tool to use to download.
> >User can choose git, as in the sample file, svn, ftp, or wget,
> >or other preferred tools.
> >NOTE, this requires that the download tool is installed in the
> >guest, or the tools have been placed in winutils.iso.
> > 3. rsc_server,
> >Resource server which contains the AutoIt script
> >and provide a download service.
> > 4. dst_rsc_dir,
> >Destination of the AutoIt scripts in the guest.
> >i.e. the downloaded resource will be saved in this default dir.
> > 5. autoit_entry,
> >Which .au3 file to start to run.
> >this will be useful if a test involves several .au3 files.
> > 
> > Signed-off-by: Cao, Chen 
> 
> I haven't reviewed the code yet, but I have 2 quick questions:
> 
> - If the files we'll be downloading are text files (.au3 files), then
> why not download them in the host and send them to the guest using
> the echo method?  This imposes less requirements on the guest.
> 

downloading/preparing them in the host also requires extra effects
before the test.

and we may also need testing tools, which are binary executables,
to aid our tests. then we have to wait for the improved rss.exe,
it is bad for the users/testers.

> - Why not add the ability to send multiple files from the host to the
> guest, using the echo method, without downloading them?
> 
> BTW, this echo method is meant to be used only until we add file
> transfer support to rss.exe (I'm not sure when exactly that will
> happen).
>  

I just like to give the users/testers more choices to focus on the tests.
especially, for now it is a little hard to echo multiple files into guest.

I am also looking forward to the new version of rss with file transfer
functions.

Thanks for your questions, buddy.


Regards,

Cao, Chen
2009/12/01

> 
> > ---
> >  client/tests/kvm/kvm_tests.cfg.sample |6 
> >  client/tests/kvm/tests/autoit.py  |   45
> > ++--
> >  2 files changed, 37 insertions(+), 14 deletions(-)
> > 
> > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > b/client/tests/kvm/kvm_tests.cfg.sample
> > index 5e15b30..f688b97 100644
> > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > @@ -169,6 +169,12 @@ variants:
> >  variants:
> >  - notepad:
> >  autoit_script = autoit/notepad1.au3
> > +- stub:
> > +download = yes
> > +download_cmd = "git clone"
> > +rsc_server = "git://the.resource.server/autoit"
> > +dst_rsc_dir = "C:\"
> > +autoit_entry = "C:\autoit\stub\stub.au3"
> >  
> >  - guest_s4: install setup unattended_install
> >  type = guest_s4
> > diff --git a/client/tests/kvm/tests/autoit.py
> > b/client/tests/kvm/tests/autoit.py
> > index 9435d7c..ed1d491 100644
> > --- a/client/tests/kvm/tests/autoit.py
> > +++ b/client/tests/kvm/tests/autoit.py
> > @@ -25,23 +25,40 @@ def run_autoit(test, params, env):
> >  # Collect test parameters
> >  binary = params.get("autoit_binary")
> >  script = params.get("autoit_script")
> > +autoit_entry = params.get("autoit_entry", "script.au3")
> >  script_params = params.get("autoit_script_params", "")
> >  timeout = float(params.get("autoit_script_timeout", 600))
> >  
> > -# Send AutoIt script to guest (this code will be replaced
> > once we
> > -# support sending files to Windows guests)
> > -session.get_command_output("del script.au3",
> > internal_timeout=0)
> > -file = open(kvm_utils.get_path(test.bindir, script))
> > -for line in file.readlines():
> > -# Insert a '^' before each character
> > -line = ""

Re: [Autotest] [KVM-AUTOTEST PATCH] Improve kvm subtest AutoIt - add option to download script from remote server

2009-12-02 Thread Cao, Chen 
Hi, Lucas,

On Thu, Dec 03, 2009 at 01:16:27AM -0200, Lucas Meneghel Rodrigues wrote:
> Chen, I have verified your patch, code looks good, but I am indeed a
> bit concerned about putting extra requirements on winutils.iso. How
> hard it is to get git working under windows? I did some quick research
> and seems that we have a portable version of git that could be kept on
> winutils.iso for that matter. Please let me know how you guys are
> doing this.
> 

We have had msysgit <http://code.google.com/p/msysgit/> pre-installed in
windows guests for internal testings, actually for a long time.

> So even though the generic idea looks fine, I am a bit concerned about
> the defaults you've put in, so I will wait for your considerations
> about how exactly we are planning to get git under the windows guests,
> OK?

I think the download method is just an option that frees the users.
and we do not require the defaults.

because if the users do not like the git way, they could use
rss.exe to echo/transfer the files into guests as we provide now,
however, they should do some preparations on host anyway,
i.e. put the scripts/resource files in the hosts
(using scp/git/svn/wget/nfs/any_other_way, which also demands
the pre-existance of extra tools).

if users like to try the download method, they can also use wget,
svn, or even ftp (with command file from the command line), we
just try to provide options but not limitations.


For your concerns, I think you mean to make autotest(kvm)
easy to use, and more user-friendly, but from my point of view,
it is very hard to let a user take actually advantages from the
autotest framework and the kvm subtests if s/he knows nothing or
very little about these.


Besides, I think the best argument for the download method is that
the rss.exe way does not meet the testing requirements.
our tests involve binary testing tools for floating point tests, for
example, and video/audio files for multimedia tests, and other
non-text files, which we cannot manage with only rss.exe, at least
for now.

So, I suggest we make our testcases more open.


Thanks for your review, advice and extra researching effort.


Regards,

Cao, Chen
2009/12/03

> 
> On Tue, Dec 1, 2009 at 8:17 AM, Cao, Chen  wrote:
> > On Tue, Dec 01, 2009 at 02:49:43AM -0500, Michael Goldish wrote:
> >>
> >> - "Chen Cao"  wrote:
> >>
> >> > Add an option to let user download the .au3 script from a remote
> >> > server, and keep the original method to prepare the script.
> >> >
> >> > This makes it possible to employ AutoIt tests that involve several
> >> > files.
> >> >
> >> > new variants:
> >> > 1. download,
> >> >    if params.get("download") == "yes", download the scripts to guest,
> >> >    else use the original method, echo the code into guest.
> >> > 2. download_cmd,
> >> >    What tool to use to download.
> >> >    User can choose git, as in the sample file, svn, ftp, or wget,
> >> >    or other preferred tools.
> >> >    NOTE, this requires that the download tool is installed in the
> >> >    guest, or the tools have been placed in winutils.iso.
> >> > 3. rsc_server,
> >> >    Resource server which contains the AutoIt script
> >> >    and provide a download service.
> >> > 4. dst_rsc_dir,
> >> >    Destination of the AutoIt scripts in the guest.
> >> >    i.e. the downloaded resource will be saved in this default dir.
> >> > 5. autoit_entry,
> >> >    Which .au3 file to start to run.
> >> >    this will be useful if a test involves several .au3 files.
> >> >
> >> > Signed-off-by: Cao, Chen 
> >>
> >> I haven't reviewed the code yet, but I have 2 quick questions:
> >>
> >> - If the files we'll be downloading are text files (.au3 files), then
> >> why not download them in the host and send them to the guest using
> >> the echo method?  This imposes less requirements on the guest.
> >>
> >
> > downloading/preparing them in the host also requires extra effects
> > before the test.
> >
> > and we may also need testing tools, which are binary executables,
> > to aid our tests. then we have to wait for the improved rss.exe,
> > it is bad for the users/testers.
> >
> >> - Why not add the ability to send multiple files from the host to the
> >> guest, using the echo method, without downloading them?
> >>
> >> BTW, this echo method is meant to be used only until we add file
> >> transfer support to rss.exe (I'm not sure when exactl