Bug 817518 - console.log for host should be updated until whole recipeset completes
console.log for host should be updated until whole recipeset completes
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.8
Unspecified Unspecified
unspecified Severity unspecified (vote)
: 0.9.2
: ---
Assigned To: Bill Peck
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-30 07:31 EDT by Jan Stancek
Modified: 2012-08-09 04:06 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-09 04:06:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Stancek 2012-04-30 07:31:21 EDT
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 09:11:57 EDT
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 15:38:53 EDT
(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 16:14:19 EDT
We need to have multiple guests running simultaneously.
Comment 11 Bill Peck 2012-07-18 16:30:24 EDT
(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 16:48:39 EDT
(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 15:15:08 EDT
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 13:50:50 EDT
http://gerrit.beaker-project.org/#/c/1272/
Comment 16 Dan Callaghan 2012-08-09 04:06:41 EDT
Beaker 0.9.2 has been released.

Note You need to log in before you can comment on or make changes to this bug.