Bug 1027100

Summary:	rhts-compat is not enabled on RHEL4-RHEL6
Product:	[Retired] Beaker	Reporter:	xjia <xjia>
Component:	beah	Assignee:	beaker-dev-list
Status:	CLOSED NOTABUG	QA Contact:	tools-bugs <tools-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	develop	CC:	aigao, asaha, dcallagh, llim, qwan, rmancy, xtian
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:	2013-11-07 03:58:46 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 xjia 2013-11-06 07:16:59 UTC

Description of problem:
Provision RHEL4~RHEL6, and log in these system. 
[root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat
rhts-compat     0:off   1:off   2:off   3:off   4:off   5:off   6:off


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

How reproducible:
100%

Steps to Reproduce:
1.Provision one system with distro RHEL4~RHEL6
2.Log in the system
3.chkconfig --list rhts-compat

Actual results:
[root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat
rhts-compat     0:off   1:off   2:off   3:off   4:off   5:off   6:off

Expected results:
[root@dev-kvm-guest-07 ~]# chkconfig --list rhts-compat
rhts-compat     0:off   1:off   2:off   3:on   4:on   5:on   6:off


Additional info:

Comment 2 Amit Saha 2013-11-06 07:28:03 UTC

Just a note that this is not a regression caused by the fix to BZ#1012452 .

Comment 5 Nick Coghlan 2013-11-07 03:58:46 UTC

I asked Bill Peck about this, and rhts-compat tinkers with the tty settings on the system so that legacy tests think they're running with a valid tty. However, having rhts-compat running isn't compatible with logging in via the system console, so it appears /distribution/reservesys shuts down the rhts components.

I'll do some additional checking while working on bug 894159, but for now, closing this as expected behaviour when reserving the system.

Comment 6 Nick Coghlan 2013-11-07 04:39:27 UTC

It occurs to me that a better way to test this without risking interference from /distribution/reservesys would be to actually run a test case using /distribution/command that checked the state of chkconfig --list rhts-compat when reservesys *wasn't* running.

The main point Bill made was that tasks and recipes can request for rhts-compat to be switched off and on, so it's not just a matter of provisioning a system through the scheduler and then logging in to check the current state.

Comment 7 Amit Saha 2013-11-07 04:49:40 UTC

(In reply to Nick Coghlan from comment #6)
> It occurs to me that a better way to test this without risking interference
> from /distribution/reservesys would be to actually run a test case using
> /distribution/command that checked the state of chkconfig --list rhts-compat
> when reservesys *wasn't* running.

That's a good idea. That will allow us to check the state when we don't change the boot state of rhts-compat.

Comment 8 Amit Saha 2013-11-07 06:16:29 UTC

(In reply to Amit Saha from comment #7)
> (In reply to Nick Coghlan from comment #6)
> > It occurs to me that a better way to test this without risking interference
> > from /distribution/reservesys would be to actually run a test case using
> > /distribution/command that checked the state of chkconfig --list rhts-compat
> > when reservesys *wasn't* running.
> 
> That's a good idea. That will allow us to check the state when we don't
> change the boot state of rhts-compat.

Turns out to be:

rhts-compat    	0:off	1:off	2:off	3:on	4:on	5:on	6:off