Bug 1387649

Summary:	rhts_task/exit always failing on RHEL-6.9-20161021.n.0 Server/s390x
Product:	[Retired] Beaker	Reporter:	Marian Ganisin <mganisin>
Component:	beah	Assignee:	beaker-dev-list
Status:	CLOSED NOTABUG	QA Contact:	tools-bugs <tools-bugs>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	23	CC:	bpeck, dcallagh, mjia, rjoost
Target Milestone:	---	Keywords:	TestBlocker
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-24 10:01:22 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:

Comment 2 Dan Callaghan 2016-10-24 00:49:48 UTC

From the console log, it seems the error is:

+ /usr/bin/rhts-test-runner.sh                                                   
HOSTNAME is not defined                                                          
+ rc=1

Comment 3 Dan Callaghan 2016-10-24 00:54:56 UTC

... which makes it a dupe of bug 1072260 (which was CLOSED WORKSFORME because we couldn't figure out how to reproduce it).

Comment 5 Dan Callaghan 2016-10-25 05:45:18 UTC

Marian, just wondering if this means there really was a bug in some RHEL component causing HOSTNAME not to be set? Or just the problem is non reproducible?

I think we could work around it in the rhts scripts, if necessary -- I was just trying to understand exactly how it can happen.

Comment 6 Marian Ganisin 2016-10-25 11:45:41 UTC

(In reply to Dan Callaghan from comment #5)
> Marian, just wondering if this means there really was a bug in some RHEL
> component causing HOSTNAME not to be set? Or just the problem is non
> reproducible?
> 
> I think we could work around it in the rhts scripts, if necessary -- I was
> just trying to understand exactly how it can happen.

Sorry for so "brief" closing comment, it wasn't intentional (just quick fingers and couple of tasks made in parallel).

So far we reported another Bug 1388037 against RHEL-6.9, that one could be cause also of issue described here (later we noticed also missing login prompt in console.log, that was clue).

While having harness resistent to possible issues would be clear advantage (easier debugging, more tests executed, ...), according to description from that another bug I expect this specific issue can't be perfectly avoided unfortunately (despite to success of restraint).

Last but not least, curiously the example with restraint provided by Bill revealed that a 'more robust' harness could lead to false negative (missed issue). If you look into console.log of Bill's job, you won't find login: prompt either (== likely affected by same issue)

Comment 7 Bill Peck 2016-10-25 12:15:42 UTC

I think having an actual test case for this situation is better than relying on the test infrastructure to happen to show it.

Comment 8 Dan Callaghan 2016-10-25 23:41:52 UTC

Okay, so to sum up... the fact that beah relies on HOSTNAME being set is fine, because bash promises that, so it's a bug (somewhere) in the distro if HOSTNAME is not set.

The fact that restraint doesn't rely on HOSTNAME being set is fine too, it's just an implementation choice in the harness.

Therefore this is NOTABUG. Right?