Bug 730710 - No logs in aborted jobs on virtual machines
Summary: No logs in aborted jobs on virtual machines
Keywords:
Status: CLOSED DUPLICATE of bug 655009
Alias: None
Product: Beaker
Classification: Community
Component: web UI
Version: 0.7
Hardware: All
OS: All
medium
medium vote
Target Milestone: ---
Assignee: Raymond Mancy
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-15 13:25 UTC by Zbysek MRAZ
Modified: 2014-12-08 01:09 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-01 04:12:11 UTC


Attachments (Terms of Use)

Description Zbysek MRAZ 2011-08-15 13:25:27 UTC
The jobs were scheduled with --systype Virtual for the TCMS run 25267.

See https://beaker.engineering.redhat.com/jobs/105669 for successfull job for the same run.

All of them aborted, some immediately, some after short time.

https://beaker.engineering.redhat.com/jobs/120208
https://beaker.engineering.redhat.com/jobs/120215

Comment 1 Bill Peck 2011-08-15 13:41:41 UTC
Sorry, Those virtual systems can't be scheduled as regular recipes.  Those
guest=* systems are simply place holders in dns for virtual machines which are
dynamically brought up on other test systems.  

You should use <hypervisor op="=" value="kvm"/> for example.

Sorry for the confusion but we have two different types of virtual in beaker
right now.  Eventually we will get rid of the need to have all those place
holder dns names.  But that won't be for a while.

Comment 2 David Kovalsky 2011-08-15 13:57:53 UTC
Hi Bill, 

can we keep this open as an RFE for better logging? 

Until the placeholders go away as you mention, could Beaker at least add a simple log line pointing people how to work with the virtuals (?)

Platform QE is experimenting if we can run our regular tiers on KVM (and thus other virtuals) so anything which will make it easier is highly welcome.

And it never hurts to have a proper error message on what's going on :-)

Comment 3 Bill Peck 2011-08-15 14:07:33 UTC
(In reply to comment #2)
> Hi Bill, 
> 
> can we keep this open as an RFE for better logging? 
> 
> Until the placeholders go away as you mention, could Beaker at least add a
> simple log line pointing people how to work with the virtuals (?)
> 
> Platform QE is experimenting if we can run our regular tiers on KVM (and thus
> other virtuals) so anything which will make it easier is highly welcome.
> 
> And it never hurts to have a proper error message on what's going on :-)

I don't understand.  There is no logging I could capture.

Comment 4 David Kovalsky 2011-08-15 14:25:41 UTC
OK, maybe I'm misunderstanding how Beaker works. 

My line of thinking is that
 * user schedules a job the way Zbysek did
 * Beaker knows it's going to fail, because without '<hypervisor op="=" value="kvm"/>' the operation is not supported ATM
 * jobs get silently aborted instead of an error message visible in Web UI that this is not supported and there's proper way to do it

So scheduler (?) could write virt-unsupported.log (or similar) saying "what you're trying to do is unsupported because of <link>. See <link>documentation</link>.

Or is that not possible with the architecture we have ATM?

Comment 5 Bill Peck 2011-08-15 14:32:42 UTC
There are lots of combinations that don't make sense.  The scheduler simply states that it doesn't match anything.

Comment 6 Zbysek MRAZ 2011-08-15 14:37:44 UTC
Shouldn't beaker itself schedule jobs with <hypervisor op="=" value="kvm"/> for example, when using --systype=virtual within XML instead of just scheduling on nonexistin guest-* machines ?

Comment 7 Bill Peck 2011-09-27 12:57:01 UTC
We have to fix a couple of things first.

We need to update scheduler to not need static guest names when using <guest> recipes, then remove the old guest-* entries.

Then systype=virtual will mean the actual real virtual machines that are usable.

Comment 8 Marian Csontos 2011-09-27 13:36:33 UTC
Why not just hide them? Is there any reason to have them listed?

We may still want them linked from Recipe page (May be just for consistency) but on list of systems these are just pointless.

Could we just use better defaults for filters and allow user to add/remove clauses in filter form?

Are there any other systems to hide by default?

For example one is usually not interested in Broken (and almost never in Removed) machines unless owner, lab-admin or in dire need of certain hardware (yes, that's what Available list is for...)

Also having predefined filters would allow easy moving among Free/Available/All system views by simply removing a clause from filter.

I am sometimes looking for a Free machine but when there is none I would have to go to Available page and repeat the query (but I just do s/Free/Avaialble/ on the URL) and eventually repeat with All to have the machine Loaned to me.

This may be better served by providing links: Free > Available > All on the system's page (for example next to "Toggle Search" link.)

Comment 9 Raymond Mancy 2012-06-08 00:54:15 UTC
The only reason I can think where having them them listed is useful, is when diagnosing install problems related to guest install. (i.e if there are no virt machine then there will be problems...). 


I like the idea of the link to the same search via Free/Available/All.

Comment 10 Dan Callaghan 2012-11-01 04:12:11 UTC
We have finally fixed this (as bug 655009). There will be no more type=Virtual.

*** This bug has been marked as a duplicate of bug 655009 ***


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