Bug 963120 - Make documentation of task/recipe roles consistent
Make documentation of task/recipe roles consistent
Status: NEW
Product: Beaker
Classification: Community
Component: Doc (Show other bugs)
Unspecified Unspecified
medium Severity unspecified (vote)
: ---
: ---
Assigned To: beaker-dev-list
: Documentation, Triaged
Depends On: 960317
  Show dependency treegraph
Reported: 2013-05-15 03:43 EDT by Nick Coghlan
Modified: 2018-02-05 19:41 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 960317
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nick Coghlan 2013-05-15 03:43:14 EDT
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 04:00:34 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.