Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1686147

Summary:	[Beaker 26.3] documentation suggested use of <hostRequires force="my.host.example.com" /> is bad idea
Product:	[Retired] Beaker	Reporter:	PaulB <pbunyan>
Component:	Doc	Assignee:	Carol Bouchard <cbouchar>
Status:	CLOSED NEXTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	26	CC:	abenoit, apowers, bpeck, breilly, cbeer, ernunes, gbaker, jbastian, jfeeney, mastyk, pbunyan, rihogan, rvr, sdoherty, tklohna
Target Milestone:	26.5	Keywords:	EasyFix, Patch
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-18 06:47:27 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 PaulB 2019-03-06 20:06:10 UTC

Description of problem:
[Beaker 26.3] documentation suggested use of  <hostRequires force="my.host.example.com" />  is bad idea.

By using force the system will be selected if its broken, manual, or excluded.
This is bad idea as users will then likely report an issue if the system fails.
The use of force is more of an admin testing/troubleshooting option.


Common Beaker users that want to target systems should not use the force for target testing systems. 

Common Beaker users should be use the following for target testing systems:
<hostRequires>
 <and>
   <hostname op="=" value="gigabyte-r120-01.khw3.lab.eng.bos.redhat.com"/>
  </and>
<system_type value="Machine"/>
</hostRequires>

Or they could use the following to cast a bigger net for any system with a similar FQDN (note the % in the FQDN):
<hostRequires>
 <and>
   <hostname op="like" value="gigabyte-r120%bos%"/>
  </and>
<system_type value="Machine"/>
</hostRequires>

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

Best,
-pbunyan

Comment 1 Martin Styk 2019-03-07 08:01:14 UTC

"If you want your recipe to run on a particular system and you know its FQDN, you can skip the host filtering described above and force the scheduler to pick a particular system for your recipe by using the force="" attribute. For example, the following XML will force the recipe to be scheduled on my.host.example.com"

I think it is clear in the documentation what you want to achieve with it. "run on a particular system" so you should be aware of the situation with particular system.

Comment 2 Martin Styk 2019-03-07 08:13:49 UTC

I would rather extend this documentation with your suggestion and keep this section there.
We have users which are using this feature as it is intended, for example, RTT team.

Comment 3 Tomas Klohna 🔧 2019-03-07 11:40:57 UTC

Are you seeing a surge of users doing this and then reporting the system as broken?
If yes, the documentation can be reworded but otherwise I agree with Martin.

As for the expanding the documentation with usage of "%", I have spawned another ticket https://bugzilla.redhat.com/show_bug.cgi?id=1686401

Comment 4 PaulB 2019-03-07 13:57:30 UTC

(In reply to Martin Styk from comment #2)
> I would rather extend this documentation with your suggestion and keep this
> section there.
> We have users which are using this feature as it is intended, for example,
> RTT team.

All,
The systems owned and managed buy the kernel-hw team are (for the most part)
available to "group everyone". The systems that are managed by the kernel-hw
group have the Beaker Condition (Automated/Broken/Manual/Removed) and Excluded 
Families intentionally set. The use of the <hostRequires force="$FQDN" /> attribute 
overrides these settings.

I am not sure why RTT needs override the Beaker system settings.
One of the other options should suit their needs.
An override of the Beaker system settings should be used for 
investigation/troubleshooting, unless the systems setting are simply wrong.

The current Beaker documentation only lists the use of force and this is a bad idea
for the reason noted here. I think it best to educate the users and and suggest 
they not override the Beaker systems settings.

I think the documentation should suggest Beaker users use 
<hostname op="=" value="$FQDN"/>
-or-
<hostname op="like" value="$PARTIAL%FQDN%"/>


Best,
-pbunyan

Comment 5 Bill Peck 2019-03-07 14:47:30 UTC

I just want add a +1 comment #4.  force should only be needed by those administering the hosts in beaker (ie: a system was marked broken and you want to schedule a job to verify it is fixed before making it available to everyone).  If force is used it should not enter the mark_system_broken() logic routine because it could be running against families that are not approved for this host.

Comment 6 Bill Peck 2019-03-07 14:58:42 UTC

I just want to claify that I don't think it should be removed from the docs but it should be explained that this is not recommended for normal workflows.  Using my example above might help.  It should encourage the normal filtering and state that force should only be used in debugging infra issues with systems.

Comment 7 Martin Styk 2019-03-07 15:01:29 UTC

(In reply to Bill Peck from comment #6)
> I just want to claify that I don't think it should be removed from the docs
> but it should be explained that this is not recommended for normal
> workflows.  Using my example above might help.  It should encourage the
> normal filtering and state that force should only be used in debugging infra
> issues with systems.

Yes, I agree.
We should update the documentation with a proposal from PaulB and consider it as a normal workflow and keep current docs with extended explanation/intention for this usage.

Comment 8 Martin Styk 2019-03-08 07:01:58 UTC

*** Bug 1686401 has been marked as a duplicate of this bug. ***

Comment 9 Martin Styk 2019-03-20 08:51:14 UTC

PaulB are you fine with it?

We will update the documentation with workflow mentioned by you and encourage users to use it, but we will also keep hostRequires with an additional note that this should be mainly used for troubleshooting purposes.

Comment 10 PaulB 2019-03-27 12:32:25 UTC

(In reply to Martin Styk from comment #9)
> PaulB are you fine with it?
> 
> We will update the documentation with workflow mentioned by you and
> encourage users to use it, but we will also keep hostRequires with an
> additional note that this should be mainly used for troubleshooting purposes.

yes - I agree with bpeck comment#5.

Best,
-pbunyan