Merge branch 'devel' into 14511-updated_Userguide-main_menu.rst

docs/docsite/rst/userguide/credential_plugins.rst

@@ -45,17 +45,20 @@ Use the AWX User Interface to configure and use each of the supported 3-party se
 3. For any of the fields below the **Type Details** area that you want to link to the external credential, click the |key| button of the input field. You are prompted to set the input source to use to retrieve your secret information.
 
 .. |key| image:: ../common/images/key-mgmt-button.png
-
+   :alt: Icon for managing external credentials
 .. image:: ../common/images/credentials-link-credential-prompt.png 
+   :alt: Credential section of the external secret management system dialog
 
 4. Select the credential you want to link to, and click **Next**. This takes you to the **Metadata** tab of the input source. This example shows the Metadata prompt for HashiVault Secret Lookup. Metadata is specific to the input source you select. See the :ref:`ug_metadata_creds_inputs` table for details.
 
 .. image:: ../common/images/credentials-link-metadata-prompt.png
+   :alt: Metadata section of the external secret management system dialog
 
 5. Click **Test** to verify connection to the secret management system. If the lookup is unsuccessful, an error message like this one displays:
 
 .. image:: ../common/images/credentials-link-metadata-test-error.png
-
+   :alt: Example exception dialog for credentials lookup
+
 6. When done, click **OK**. This closes the prompt window and returns you to the Details screen of your target credential. **Repeat these steps**, starting with :ref:`step 3 above <ag_credential_plugins_link_step>` to complete the remaining input fields for the target credential. By linking the information in this manner, AWX retrieves sensitive information, such as username, password, keys, certificates, and tokens from the 3rd-party management systems and populates that data into the remaining fields of the target credential form.
 
 7. If necessary, supply any information manually for those fields that do not use linking as a way of retrieving sensitive information. Refer to the appropriate :ref:`ug_credentials_cred_types` for more detail about each of the fields.
@@ -200,7 +203,7 @@ You need the Centrify Vault web service running to store secrets in order for th
 Below shows an example of a configured CyberArk AIM credential.
 
 .. image:: ../common/images/credentials-create-centrify-vault-credential.png 
-
+   :alt: Example new centrify vault credential lookup dialog
 
 .. _ug_credentials_cyberarkccp:
 
@@ -222,7 +225,7 @@ You need the CyberArk Central Credential Provider web service running to store s
 Below shows an example of a configured CyberArk CCP credential.
 
 .. image:: ../common/images/credentials-create-cyberark-ccp-credential.png 
-
+   :alt: Example new CyberArk vault credential lookup dialog
 
 .. _ug_credentials_cyberarkconjur:
 
@@ -245,7 +248,7 @@ When **CyberArk Conjur Secrets Manager Lookup** is selected for **Credential Typ
 Below shows an example of a configured CyberArk Conjur credential.
 
 .. image:: ../common/images/credentials-create-cyberark-conjur-credential.png
-
+   :alt: Example new CyberArk Conjur Secret lookup dialog
 
 .. _ug_credentials_hashivault:
 
@@ -268,7 +271,7 @@ When **HashiCorp Vault Secret Lookup** is selected for **Credential Type**, prov
 For more detail about Approle and its fields, refer to the `Vault documentation for Approle Auth Method <https://www.vaultproject.io/docs/auth/approle>`_.  Below shows an example of a configured HashiCorp Vault Secret Lookup credential.
 
 .. image:: ../common/images/credentials-create-hashicorp-kv-credential.png 
-
+   :alt: Example new HashiCorp Vault Secret lookup dialog
 
 .. _ug_credentials_hashivaultssh:
 
@@ -292,7 +295,7 @@ For more detail about Approle and its fields, refer to the `Vault documentation
 Below shows an example of a configured HashiCorp SSH Secrets Engine credential.
 
 .. image:: ../common/images/credentials-create-hashicorp-ssh-credential.png 
-
+   :alt: Example new HashiCorp Vault Signed SSH credential lookup dialog
 
 .. _ug_credentials_azurekeyvault:
 
@@ -314,7 +317,7 @@ When **Microsoft Azure Key Vault** is selected for **Credential Type**, provide
 Below shows an example of a configured Microsoft Azure KMS credential.
 
 .. image:: ../common/images/credentials-create-azure-kms-credential.png
-
+   :alt: Example new Microsoft Azure Key Vault credential lookup dialog
 
 .. _ug_credentials_thycoticvault:
 
@@ -334,6 +337,7 @@ When **Thycotic DevOps Secrets Vault** is selected for **Credential Type**, prov
 Below shows an example of a configured Thycotic DevOps Secrets Vault credential.
 
 .. image:: ../common/images/credentials-create-thycotic-devops-credential.png
+   :alt: Example new Thycotic DevOps Secrets Vault credential lookup dialog
 
 
 
@@ -354,5 +358,6 @@ When **Thycotic Secrets Server** is selected for **Credential Type**, provide th
 Below shows an example of a configured Thycotic Secret Server credential.
 
 .. image:: ../common/images/credentials-create-thycotic-server-credential.png
+   :alt: Example new Thycotic Secret Server credential lookup dialog
 
 

docs/docsite/rst/userguide/workflows.rst

@@ -1,25 +1,22 @@
 .. _ug_workflows:
 
-
 Workflows
 ============
 
 .. index::
    single: workflows
-
-Workflows allow you to configure a sequence of disparate job templates (or workflow templates) that may or may not share inventory, playbooks, or permissions. However, workflows have ‘admin’ and ‘execute’ permissions, similar to job templates. A workflow accomplishes the task of tracking the full set of jobs that were part of the release process as a single unit. 
 
+Workflows allow you to configure a sequence of disparate job templates (or workflow templates) that may or may not share inventory, playbooks, or permissions. However, workflows have ‘admin’ and ‘execute’ permissions, similar to job templates. A workflow accomplishes the task of tracking the full set of jobs that were part of the release process as a single unit.
 
 Job or workflow templates are linked together using a graph-like structure called nodes. These nodes can be jobs, project syncs, or inventory syncs. A template can be part of different workflows or used multiple times in the same workflow. A copy of the graph structure is saved to a workflow job when you launch the workflow.
 
 The example below shows a workflow that contains all three, as well as a workflow job template:
 
 .. image:: ../common/images/wf-node-all-scenarios-wf-in-wf.png
-
+   :alt: Workflow Node All Scenarios
 
 As the workflow runs, jobs are spawned from the node's linked template. Nodes linking to a job template which has prompt-driven fields (``job_type``, ``job_tags``, ``skip_tags``, ``limit``) can contain those fields, and will not be prompted on launch. Job templates with promptable credential and/or inventory, WITHOUT defaults, will not be available for inclusion in a workflow.
 
-
 Workflow scenarios and considerations
 ----------------------------------------
 
@@ -28,34 +25,38 @@ Consider the following scenarios for building workflows:
 - A root node is set to ALWAYS by default and it not editable.
 
 .. image:: ../common/images/wf-root-node-always.png
+   :alt: Root Node Always
 
-- A node can have multiple parents and children may be linked to any of the states of success, failure, or always. If always, then the state is neither success or failure. States apply at the node level, not at the workflow job template level. A workflow job will be marked as successful unless it is canceled or encounters an error. 
+- A node can have multiple parents and children may be linked to any of the states of success, failure, or always. If always, then the state is neither success or failure. States apply at the node level, not at the workflow job template level. A workflow job will be marked as successful unless it is canceled or encounters an error.
 
 .. image:: ../common/images/wf-sibling-nodes-all-edge-types.png
+   :alt: Sibling Nodes All Edge Types
 
 - If you remove a job or workflow template within the workflow, the node(s) previously connected to those deleted, automatically get connected upstream and retains its edge type as in the example below:
 
 .. image:: ../common/images/wf-node-delete-scenario.png
+   :alt: Node Delete Scenario
 
-- You could have a convergent workflow, where multiple jobs converge into one. In this scenario, any of the jobs or all of them must complete before the next one runs, as shown in the example below: 
+- You could have a convergent workflow, where multiple jobs converge into one. In this scenario, any of the jobs or all of them must complete before the next one runs, as shown in the example below:
 
-  .. image:: ../common/images/wf-node-convergence.png
+.. image:: ../common/images/wf-node-convergence.png
+   :alt: Node Convergence
 
 In the example provided, AWX runs the first two job templates in parallel. When they both finish and succeed as specified, the 3rd downstream (:ref:`convergence node <convergence_node>`), will trigger.
 
 - Prompts for inventory and surveys will apply to workflow nodes in workflow job templates.
 
-- If you launch from the API, running a ``get`` command displays a list of warnings and highlights missing components. The basic workflow for a workflow job template is illustrated below. 
+- If you launch from the API, running a ``get`` command displays a list of warnings and highlights missing components. The basic workflow for a workflow job template is illustrated below.
 
 .. image:: ../common/images/workflow-diagram.png
+   :alt: Workflow Diagram
 
-- It is possible to launch several workflows simultaneously, and set a schedule for when to launch them. You can set notifications on workflows, such as when a job completes, similar to that of job templates. 
+- It is possible to launch several workflows simultaneously, and set a schedule for when to launch them. You can set notifications on workflows, such as when a job completes, similar to that of job templates.
 
 .. note::
 
   .. include:: ../common/job-slicing-rule.rst
 
-
 - You can build a recursive workflow, but if AWX detects an error, it will stop at the time the nested workflow attempts to run.
 
 - Artifacts gathered in jobs in the sub-workflow will be passed to downstream nodes.
@@ -70,7 +71,6 @@ In the example provided, AWX runs the first two job templates in parallel. When
 
 - In a workflow convergence scenario, ``set_stats`` data will be merged in an undefined way, so it is recommended that you set unique keys.
 
-
 Extra Variables
 ----------------
 
@@ -83,6 +83,7 @@ Also similar to job templates, workflows use surveys to specify variables to be
 Workflows utilize the same behavior (hierarchy) of variable precedence as Job Templates with the exception of three additional variables. Refer to the Variable Precedence Hierarchy in the :ref:`ug_jobtemplates_extravars` section of the Job Templates chapter of this guide. The three additional variables include:
 
 .. image:: ../common/images/Architecture-AWX_Variable_Precedence_Hierarchy-Workflows.png
+   :alt: Variable Precedence Hierarchy
 
 Workflows included in a workflow will follow the same variable precedence - they will only inherit variables if they are specifically prompted for, or defined as part of a survey.
 
@@ -108,7 +109,6 @@ If you use the ``set_stats`` module in your playbook, you can produce results th
           data:
             integration_results_url:  "{{ (result.stdout|from_json).link }}"
 
-
 - **use_set_stats.yml**: second playbook in the workflow
 
 ::
@@ -121,47 +121,44 @@ If you use the ``set_stats`` module in your playbook, you can produce results th
           url: "{{ integration_results_url }}"
           return_content: true
         register: results
-        
+
       - name: "Output test results"
         debug:
           msg: "{{ results.content }}"
 
-
 The ``set_stats`` module processes this workflow as follows:
 
-1. The contents of an integration results (example: integration_results.txt below) is first uploaded to the web. 
+1. The contents of an integration results (example: integration_results.txt below) is first uploaded to the web.
 
 ::
 
-	the tests are passing!
+    the tests are passing!
 
 2. Through the **invoke_set_stats** playbook, ``set_stats`` is then invoked to artifact the URL of the uploaded integration_results.txt into the Ansible variable "integration_results_url".
 3. The second playbook in the workflow consumes the Ansible extra variable "integration_results_url". It calls out to the web using the ``uri`` module to get the contents of the file uploaded by the previous Job Template Job. Then, it simply prints out the contents of the gotten file.
 
-.. note:: 
-
-  For artifacts to work, keep the default setting, ``per_host = False`` in the ``set_stats`` module. 
+.. note::
 
+  For artifacts to work, keep the default setting, ``per_host = False`` in the ``set_stats`` module.
 
 Workflow States
 ----------------
 
 The workflow job can have the following states (no Failed state):
 
-- Waiting 
+- Waiting
 
 - Running
 
 - Success (finished)
 
-- Cancel 
+- Cancel
 
 - Error
 
 - Failed
 
-In the workflow scheme, canceling a job cancels the branch, while canceling the workflow job cancels the entire workflow.  
-
+In the workflow scheme, canceling a job cancels the branch, while canceling the workflow job cancels the entire workflow.
 
 Role-Based Access Controls
 -----------------------------
@@ -174,6 +171,4 @@ Other tasks such as the ability to make a duplicate copy and re-launch a workflo
 
 .. ^^
 
-For more information on performing the tasks described in this section, refer to the :ref:`Administration Guide <ag_start>`. 
-
-
+For more information on performing the tasks described in this section, refer to the :ref:`Administration Guide <ag_start>`.