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
"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.
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.
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
(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
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.
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.
(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.
*** Bug 1686401 has been marked as a duplicate of this bug. ***
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.
(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