Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 817518

Summary:	console.log for host should be updated until whole recipeset completes
Product:	[Retired] Beaker	Reporter:	Jan Stancek <jstancek>
Component:	scheduler	Assignee:	Bill Peck <bpeck>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.8	CC:	bpeck, dcallagh, gozen, jburke, pbunyan, rmancy, stl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-09 08:06:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Stancek 2012-04-30 11:31:21 UTC

Description of problem:
When running guest testing, host's console.log contains data only for so long as host recipe is running. So if there is panic on host after last task on host finished you can't find out why the host panic'd.

This is presumably because lab controller is not updating console.log to scheduler after host recipe finishes. Lab controller can still tell there was a panic and it will set recipe result to "panic".

Version-Release number of selected component (if applicable):
0.8.2

How reproducible:
100%

Steps to Reproduce:
1. run recipeset host + guest
2. install host, when last task on host finishes crash the host

Actual results:
panic message is not in console.log

Expected results:
console.log for host should contain all output while recipeset is running

Additional info:

Comment 7 Bill Peck 2012-07-18 13:11:57 UTC

To make this as seemless as possible I could modify virt/start_stop to do this.  The no additional task would be required.

Comment 9 Gurhan Ozen 2012-07-18 19:38:53 UTC

(In reply to comment #7)
> To make this as seemless as possible I could modify virt/start_stop to do
> this.  The no additional task would be required.

I am guessing that the workflow of the virt/start_stop test will be something like :
  -- find the guest's recipeid from the LC
  -- start the guest
  -- keep on querying the LC about the guests state and wait until it's in finished state 
  -- shutdown the guest. 

That's doable I guess, however everyone that uses /virt/start will have to change to /virt/start_stop and it won't be possible to have multiple guests running simultaneously.

Comment 10 Jeff Burke 2012-07-18 20:14:19 UTC

We need to have multiple guests running simultaneously.

Comment 11 Bill Peck 2012-07-18 20:30:24 UTC

(In reply to comment #9)
> (In reply to comment #7)
> > To make this as seemless as possible I could modify virt/start_stop to do
> > this.  The no additional task would be required.
> 
> I am guessing that the workflow of the virt/start_stop test will be
> something like :
>   -- find the guest's recipeid from the LC
>   -- start the guest
>   -- keep on querying the LC about the guests state and wait until it's in
> finished state 
>   -- shutdown the guest. 
> 
> That's doable I guess, however everyone that uses /virt/start will have to
> change to /virt/start_stop and it won't be possible to have multiple guests
> running simultaneously.

Why would it be limited to one guest running at a time?

Comment 12 Gurhan Ozen 2012-07-18 20:48:39 UTC

(In reply to comment #11)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > To make this as seemless as possible I could modify virt/start_stop to do
> > > this.  The no additional task would be required.
> > 
> > I am guessing that the workflow of the virt/start_stop test will be
> > something like :
> >   -- find the guest's recipeid from the LC
> >   -- start the guest
> >   -- keep on querying the LC about the guests state and wait until it's in
> > finished state 
> >   -- shutdown the guest. 
> > 
> > That's doable I guess, however everyone that uses /virt/start will have to
> > change to /virt/start_stop and it won't be possible to have multiple guests
> > running simultaneously.
> 
> Why would it be limited to one guest running at a time?

In its current set up, it would be. Right now, it just loops thru all guests and does each one of them one by one synchronously. It can definitely be rewritten to have this asynchronously though, since virsh start is an asynchronous function anyway. 
 I guess, we could do 
      -- virsh start $guest
      -- register $guest with some sort of monitoring process to query the LC about the $guest's state  
      -- move on to the next guest. 
      -- When the monitoring process finds out that all the guests are in finished state, then finish the job. 

 However, then EVERY test would be running the guests simultaneously. This might not be desirable, the host might not have enough resources to run all the guests at once . 
  Pick your favorite poison;)

Comment 14 Bill Peck 2012-08-01 19:15:08 UTC

I found the bug which prevents console logs from being uploaded while the recipeset is active.

Uploading the console logs for guests is a separate issue and should be filed in another bz.

Comment 15 Bill Peck 2012-08-02 17:50:50 UTC

http://gerrit.beaker-project.org/#/c/1272/

Comment 16 Dan Callaghan 2012-08-09 08:06:41 UTC

Beaker 0.9.2 has been released.