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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-06-25 at 08:21 +0000, Pang, LongtaoX wrote:
> 
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > Sent: Wednesday, June 17, 2015 5:35 PM
> > To: Pang, LongtaoX
> > Cc: Hu, Robert; Ian Jackson; xen-devel@xxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx
> > 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@xxxxxxxxxxxxxx xl list
> > > 2015-06-17 08:10:25 Z executing ssh ... root@xxxxxxxxxxxxxx ps -wwef
> > > 2015-06-17 08:10:25 Z executing ssh ... root@xxxxxxxxxxxxxx ps -wwef
> > > 2015-06-17 08:10:25 Z executing ssh ... root@xxxxxxxxxxxxxx xenstore-ls 
> > > -fp
> > > 2015-06-17 08:10:26 Z executing ssh ... root@xxxxxxxxxxxxxx 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.
> > 
> > > > 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.
> > 
> I have reviewed power_cycle_host_setup function, inside this function will 
> call 
> get_host_method_object, then we could get a $mo which will be assigned to 
> $ho->{PowerMethobjs}, right?

Yes. Note that PowerMethobjs is an array rather than a single scalar,
since you can have a sequence of $mo's which are needed for a given
host.

> Inside power_state function, it will call pdu_power_state which is defined in 
> guest.pm, right?

It will call $mo->pdu_power_state for each $mo in PowerMethobjs, yes.

> So, I need to defined how to power off/on L1 inside pdu_power_state function?

In a new Osstest::PDU::guest module, yes.

>  I think we
> need to using 'xl destroy' and 'xl create' command to implement the power
> method.

I think so, yes.

In one of your patches you rely on the affect of "xl block-attach"
persisting after an "xl reboot", while it won't with "xl destroy"
followed by "xl create". IOW in that patch you may want to also update
the config file too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel