Bug 963120

Summary: Update documentation of task/recipe roles to make it consistent
Product: [Retired] Beaker Reporter: Nick Coghlan <ncoghlan>
Component: DocAssignee: beaker-dev-list
Status: CLOSED WONTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: low    
Version: 0.12CC: qwan, tools-bugs
Target Milestone: ---Keywords: Documentation, EasyFix, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 960317 Environment:
Last Closed: 2020-10-21 14:13:17 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:
Bug Depends On: 960317    
Bug Blocks:    

Description Nick Coghlan 2013-05-15 07:43:14 UTC 
Task/recipe roles are covered in 3 places: in the multihost testing guide, in the XML attribute docs in the relax-NG schema for the job XML and in the main job XML documentation.

Setting "STANDALONE" or "None" as the task role isn't really needed any more, since the attribute is now optional. Roles should really only be set when you actually need them for a multihost test.

For now, due to the fact that task roles are not shared between host recipes and guest recipes, recipe roles are preferred to task roles, unless you have a specific reason to use task roles (such as running the same test more than once between two recipes with different roles each time)

The docs should be scanned for any references to task and recipe roles and updated to be consistent with the multihost testing guide.

+++ This bug was initially created as a clone of Bug #960317 +++
Comment 1 Nick Coghlan 2013-05-15 08:00:34 UTC 
Related to this, we should check that the limitations of guest roles are mentioned (in terms of whether or not the FQDNs have been populated yet), and ensure that the contents of the environment variables are correctly referred to as FQDNs rather than mere hostnames.