Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1064950 - Beaker WEB UI is not aware that task ended
Summary: Beaker WEB UI is not aware that task ended
Alias: None
Product: Beaker
Classification: Community
Component: web UI
Version: 0.15
Hardware: x86_64
OS: Linux
high vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-13 15:47 UTC by Adam Okuliar
Modified: 2018-02-06 00:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-03-18 10:21:44 UTC

Attachments (Terms of Use)

Comment 7 Dan Callaghan 2014-02-13 22:26:55 UTC
This sounds a lot like bug 1062867, which is ultimately caused by IPv6 connectivity problems during the task's execution. On RHEL7 the harness now attempts to talk to the lab controller over IPv6 where available.

Does the /performance/network-perftest task (accidentally or intentionally) break IPv6 connectivity to the lab controller? After the task has run can you log in and check whether the lab controller is reachable over IPv6?

Can you also paste a link to the job(s) where this is failing for you, so we can look at the console log? (In future it might be simpler to just link to the Beaker jobs rather than attaching a huge tarball to the bug.)

Comment 10 Adam Okuliar 2014-02-14 12:16:10 UTC
(In reply to Dan Callaghan from comment #7)

Dan this could be a problem. Atough I have 
in my network configuration, IP6 address is not assigned after

# service network restart 

(I do not use NetworkManager because of #907836).

Is there a way how to force harness to use IPv4 only? There should definitely be some.

What is DNS hostname that should be reachable for uploading results? 
(for debugging purposes)

Comment 11 Dan Callaghan 2014-02-17 00:29:21 UTC
Note that in our labs, the Beaker systems generally always get a working IPv6 configuration automatically using SLAAC as long as IPv6 is enabled (which it is by default on all recent RHELs).

The harness talks to the lab controller, its FQDN is available as $LAB_CONTROLLER in the task environment (but not if you log in to the system).

The harness falls back to IPv4 if it can't connect to the lab controller over IPv6 at the start of the task. So the problem only happens if IPv6 connectivity *was* working and then breaks during task execution. For example in the case of bug 1062867 the task was setting up a bridge which triggered a RHEL7 kernel bug with IPv6 and bridged interfaces.

There's no currently no way to tell the harness not to attempt IPv6. We could add that, but in the meantime you can opt in to an older version of the harness which doesn't have IPv6 support by passing ks_meta="beah_rpm=beah-0.6.48" in your <recipe/> (see bug 1063090).

If you can give us the job ID for some of your failing jobs, we can look at the console log to see if there are any other hints there.

Comment 12 Adam Okuliar 2014-03-18 10:21:44 UTC
(In reply to Dan Callaghan from comment #11)

> ks_meta="beah_rpm=beah-0.6.48" in your <recipe/> (see bug 1063090).

Does provide woraround for my problem. Since this is not problem of beaker but problem of RHEL (INET6 connectivity won't start after reconfiguring of network) I am clonsing this as NOTABUG

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