Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

["Pang, LongtaoX" <longtaox.pang@intel.com>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: Wednesday, June 17, 2015 5:35 PM
> To: Pang, LongtaoX
> Cc: Hu, Robert; Ian Jackson; xen-devel@lists.xen.org; wei.liu2@citrix.com
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested
> test job
> 
> On Wed, 2015-06-17 at 08:54 +0000, Pang, LongtaoX wrote:
> 
> > After executing command ' ./standalone run-job --simulate -h dummy
> test-amd64-amd64-qemuu-nested | grep testid',
> > get below information:
> > root@OSSTEST:~/v11_pretest_3/osstest_v11# ./standalone run-job --simulate -h
> dummy test-amd64-amd64-qemuu-nested | grep testid
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 1 testid build-check(1) ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 2 testid hosts-allocate ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 3 testid host-install(3) ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 4 testid host-ping-check-native ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 5 testid xen-install ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 6 testid xen-boot ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 7 testid host-ping-check-xen ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 8 testid leak-check/basis(8) ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 9 testid debian-hvm-install ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 10 testid nested-setup ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 11 testid xen-install/nestedl1 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 12 testid host-reboot/nestedl1 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 13 testid leak-check/basis/nestedl1 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 14 testid debian-hvm-install/nestedl1/nestedl2 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 15 testid guest-stop/nestedl1/nestedl2 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 16 testid guest-destroy ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 17 testid leak-check/check ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 18 testid leak-check/check/nestedl1 ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 19 testid capture-logs(19) ==========
> > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested
> ========== 20 testid capture-logs/nestedl1(20) ==========
> > root@OSSTEST:~/v11_pretest_3/osstest_v11#
> >
> > But, for testid of '18', I think it will failed to execute 'leak-check/check/nestedl1',
> since
> > 'nestedl1' has been destroyed via the action of 'run-ts . = ts-guest-destroy + host
> nestedl1'.
> > Please correct me if I am wrong.
> 
> I think you are correct, the logs capture will fail too.
> 
> I'll leave it to Ian to suggest a solution since it will no doubt
> involve some tcl plumbing (I'd be inclined to record 'hosts which are
> actually guests' somewhere and have the infra clean them up
> automatically after doing leak check and log collection).
> 
> > Another question, after execute testid of '13'(leak-check/basis/nestedl1), the
> testing will fail and exit with below message.
> > Something wrong with my test environment?
> > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xl list
> > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef
> > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef
> > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xenstore-ls -fp
> > 2015-06-17 08:10:26 Z executing ssh ... root@192.168.199.25 find /tmp /var/run
> /var/tmp /var/lib/xen /var/core ! -type d -print0 -ls -printf '\0'
> > find: `/var/core': No such file or directory
> 
> /var/core is created by ts-host-install. I think the tail end of the
> function sub in there which does that and populates /etc/sysctl.conf
> and /etc/security/limits.d/coredumps.conf should be refactored probably
> to be alongside the osstest-confirm-booted thing which IIRC you are
> already going to refactor in the next version.
> 
I reviewed related code in 'ts-host-install'. But I am not very clear, the below code will be executed 
in 'ts-debian-hvm-install' too? Or refactor 'osstest-confirm-booted' and the below action should be finished inside this shell script? 
Since, it need '/var/core' directory in L1, please correct me.

    target_cmd_root($ho, 'mkdir -p /var/core');
    target_editfile_root($ho, '/etc/sysctl.conf',
        sub { target_editfile_kvp_replace(
                  "kernel.core_pattern",
                  # %p==pid,%e==executable name,%t==timestamp
                  "/var/core/%t.%p.%e.core") });
    target_cmd_root($ho, "sysctl --load /etc/sysctl.conf");
    my $coredumps_conf = <<'END';
#<domain>      <type>  <item>       <value>
*               soft    core         -1
root            soft    core         -1
END
    target_putfilecontents_root_stash($ho,10,$coredumps_conf,
                                '/etc/security/limits.d/coredumps.conf');

> > > Perhaps arrange for an appropriate PowerMethod for "hosts which are
> > > actually guests"?
> > >
> > I think maybe we need to refactor 'power_cycle' function in TestSupport.pm. I
> have not try it, something like below?
> 
> I was thinking more along the lines of creating Osstest/PDU/guest.pm
> with the appropriate methods calling out to toolstack($l0)->foo, setting
> $ho->{Power} = 'guest $l1guestname' somewhere and allowing
> power_cycle_host_setup to do it's thing.
> 
> Ian.