FixLinks

Removed anchors to avoid broken links.

Author: rwellon

managing_providers/_topics/adding_ansible_galaxy_roles.md

@@ -1,5 +1,4 @@
 ## Installing Roles on an Embedded Ansible Appliance
-{: #installing_roles_embedded_ansible_appliance}
 
 Roles are ways of automatically loading certain variable files, tasks, and handlers based on a known file structure. Grouping content by roles also allows for easy sharing of roles with other users. Install roles on a {{ site.data.product.title_short }} appliance with the Embedded Ansible server role activated to optimize playbooks.
 

managing_providers/_topics/ansible_credentials.md

@@ -1,10 +1,8 @@
 # Credentials
-{: #ansible_credentials}
 
 Credentials are utilized by {{ site.data.product.title_short }} for authentication when running Ansible playbooks against machines, synchronizing with inventory sources, and importing project content from a version control system.
 
 ## Adding Credentials
-{: #adding_credentials}
 
 {{ site.data.product.title_short }} can store credentials used by playbooks. Credentials saved in {{ site.data.product.title_short }} are matched and executed with a playbook when run.
 
@@ -21,12 +19,10 @@ Credentials are utilized by {{ site.data.product.title_short }} for authenticati
 5.  Click **Add**.
 
 ## Credential Types
-{: #credential_types}
 
 Each credential type used by {{ site.data.product.title_short }} is detailed in the following sections.
 
 ### Machine
-{: #machine}
 
 Machine credentials enable {{ site.data.product.title_short }} to invoke Ansible on hosts under your management. Just like using Ansible on the command line, you can specify the SSH username, optionally provide a password, an SSH key, or a key password. They define SSH and user-level privilege escalation access for playbooks, and are used when running playbooks on a remote host.
 
@@ -45,7 +41,6 @@ Machine credentials enable {{ site.data.product.title_short }} to invoke Ansible
 - **Privilege Escalation Password**: Enter the actual password to be used to authenticate the user via the selected privilege escalation type on the remote system.
 
 ### Network
-{: #network}
 
 Network credentials are used by Ansible networking modules to connect to and manage networking devices.
 
@@ -64,7 +59,6 @@ Network credentials have several attributes that may be configured:
 - **Private key passphrase**: The actual passphrase for the private key to be used to authenticate the user to the network via SSH.
 
 ### SCM
-{: #scm}
 
 SCM (source control) credentials are used with Projects to clone and update local source code repositories from a remote revision control system such as Git, Subversion, or Mercurial.
 
@@ -79,7 +73,6 @@ Source Control credentials have several attributes that may be configured:
 - **Private Key**: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the source control system via SSH.
 
 ### Amazon
-{: #amazon}
 
 Selecting this credential type enables synchronization of cloud inventory with Amazon Web Services.
 
@@ -90,7 +83,6 @@ Selecting this credential type enables synchronization of cloud inventory with A
 - **STS Token**: Token generated by Amazon Web Services Security Token Service.
 
 ### Azure
-{: #azure}
 
 Selecting this credential type enables synchronization of cloud inventory with Microsoft Azure.
 
@@ -109,7 +101,6 @@ Microsoft Azure credentials have several attributes to configure:
 - **Client ID**: The Client ID for the Microsoft Azure account.
 
 ### OpenStack
-{: #openstack}
 
 Selecting this credential type enables synchronization of cloud inventory with Red Hat OpenStack Platform.
 
@@ -126,7 +117,6 @@ OpenStack credentials have several attributes that may be configured:
 - **Domain name**: The FQDN to be used to connect to OpenStack.
 
 ### Red Hat Virtualization
-{: #red_hat_virtualization}
 
 Selecting this credential type enables synchronization of cloud inventory with Red Hat Virtualization.
 
@@ -143,7 +133,6 @@ Red Hat Virtualization credentials have several attributes that may be configure
    For more information on the Ansible Roles that are available for Red Hat Virtualization, see [Ansible Roles](https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/chap-automating_rhv_configuration_using_ansible#Ansible_Roles).
 
 ### VMware
-{: #vmware}
 
 Selecting this credential type enables synchronization of inventory with VMware vCenter.
 

managing_providers/_topics/automation_management_providers.md

@@ -1,5 +1,4 @@
 # Automation Management Providers
-{: #automation_management_providers}
 
 In {{ site.data.product.title_short }}, an automation management provider is a management tool that integrates with {{ site.data.product.title_short }} to simplify automation operations for your resources. The following chapter describes the automation management providers that you can use with {{ site.data.product.title_short }}, and how to work with them.
 
@@ -12,7 +11,6 @@ In {{ site.data.product.title_short }}, an automation management provider is a m
 **Ansible Tower** is a management tool that is integrated with {{ site.data.product.title_short }}, designed to help automate infrastructure operations utlizizing existing Ansible Tower providers in your inventory. {{ site.data.product.title_short }} allows you to execute Ansible Tower jobs by using service catalogs and Automate. Using Ansible Tower, you can schedule Ansible playbook runs and monitor current and historical results, allowing for troubleshooting or identification of issues before they occur.
 
 ## Ansible
-{: #ansible}
 
 Ansible integrates with {{ site.data.product.title_short }} to provide automation solutions, using playbooks, for Service, Policy and Alert actions. Ansible playbooks consist of series of *plays* or tasks that define automation across a set of hosts, which is known as the inventory.
 
@@ -35,7 +33,6 @@ Ansible is built into {{ site.data.product.title_short }} so there is nothing to
 4. Back your services, alerts, and policies using available playbooks.
 
 ### Enabling the Embedded Ansible Server Role
-{: #enabling_embedded_ansible_server_role}
 
 In {{ site.data.product.title_short }}, the **Embedded Ansible** role is disabled by default. Enable this server role to utilize Ansible Automation Inside.
 
@@ -48,7 +45,6 @@ In {{ site.data.product.title_short }}, the **Embedded Ansible** role is disable
 3. Set the **Server Role** for **Embedded Ansible** to **On**.
 
 ### Verifying the Embedded Ansible Worker State
-{: #verifying_embedded_ansible_worker_state}
 
 Verify that the Embedded Ansible worker has started to utilize its features.
 
@@ -59,7 +55,6 @@ Verify that the Embedded Ansible worker has started to utilize its features.
 A table of all workers and current status will appear from which you can confirm the state of your embedded Ansible worker.
 
 ### Adding a Playbook Repository
-{: #adding_playbook_repository}
 
 Add a repository so that {{ site.data.product.title_short }} can discover and make available your playbooks.
 
@@ -82,7 +77,6 @@ Add a repository so that {{ site.data.product.title_short }} can discover and ma
 Once you have synced a repository, its playbooks will become available to {{ site.data.product.title_short }}.
 
 ### Refreshing Repositories
-{: #refreshing_repositories}
 
 {{ site.data.product.title_short }} allows you to refresh a targeted playbook repository or all repositories in your inventory to ensure your playbooks are current.
 
@@ -109,7 +103,6 @@ Alternately, you can refresh some or all repositories from the list view:
 {% include_relative _topics/optimizing_playbooks.md %}
 
 ### Ansible Tower
-{: #ansible_tower}
 
 Ansible Tower is a management tool integrated with {{ site.data.product.title_short }}, designed to help automate infrastructure operations. {{ site.data.product.title_short }} allows you to execute Ansible Tower jobs or workflows using service catalogs and Automate. No custom configuration or Ruby scripting is needed in {{ site.data.product.title_short }}, as configuration is done in Ansible Tower using playbooks.
 
@@ -120,7 +113,6 @@ Using Ansible Tower, you can schedule Ansible playbook runs and monitor current
 {{ site.data.product.title_short }} supports Ansible Tower API v2 provider integration.
 
 #### Working with an Ansible Tower Provider
-{: #working_with_ansible_tower_provider}
 
 The basic workflow when using {{ site.data.product.title_short }} with an Ansible Tower provider is as follows:
 
@@ -141,7 +133,6 @@ The basic workflow when using {{ site.data.product.title_short }} with an Ansibl
 - For more information about worklows, see [Workflows](https://docs.ansible.com/ansible-tower/latest/html/userguide/workflows.html) in the Ansible Tower *User Guide*.
 
 #### Adding an Ansible Tower Provider
-{: #adding_ansible_tower_provider}
 
 To access your Ansible Tower inventory from {{ site.data.product.title_short }}, you must add Ansible Tower as a provider.
 
@@ -176,7 +167,6 @@ To access your Ansible Tower inventory from {{ site.data.product.title_short }},
 After adding the Ansible Tower provider, refresh its relationships and power states in order to view the current inventory.
 
 #### Refreshing an Ansible Tower Provider
-{: #refreshing_an_ansible_tower_provider}
 
 Refresh relationships of all items related to an existing Ansible Tower configuration management provider including inventory, hosts, virtual machines, and clusters.
 
@@ -197,7 +187,6 @@ To refresh an Ansible Tower provider’s inventory in {{ site.data.product.title
 {{ site.data.product.title_short }} then queries the Ansible Tower API and obtains an inventory of all available hosts, job, and workflow templates.
 
 #### Viewing Ansible Tower Providers and Inventory
-{: #viewing_ansible_tower_providers_and_inventory}
 
 {{ site.data.product.title_short }} automatically updates its inventory from Ansible Tower. This includes system groups (known as Inventories in Ansible Tower), basic information about individual systems, and available Ansible Tower job or workflow templates to be executed from the service catalog or Automate.
 
@@ -214,7 +203,6 @@ To view a list of Ansible Tower providers and inventory:
 Similarly, all discovered job and workflow templates are accessed under the provider by expanding the menu: **Automation > Ansible Tower > Explorer** and click the **Templates** accordion menu.
 
 #### Viewing Ansible Tower Configured Systems
-{: #viewing_ansible_tower_configured_systems}
 
 To view the systems in your Ansible Tower inventory:
 
@@ -223,7 +211,6 @@ To view the systems in your Ansible Tower inventory:
 2. Under **All Ansible Tower Configured Systems**, select **Ansible Tower Configured Systems** to display a list.
 
 #### Executing an Ansible Tower Job or Workflow Template from a Service Catalog
-{: #executing_ansible_tower_job_or_workflow_template_from_service_catalog}
 
 You can execute an Ansible Tower playbook from {{ site.data.product.title_short }} by creating a service catalog item from an Ansible Tower job or workflow template.
 
@@ -288,7 +275,6 @@ The service item’s details can be viewed in menu: **Services > My Services** i
 **Note:** Instead of running a single job at a time, multiple service catalog items can also be grouped together as a catalog bundle to create one deployment with multiple job templates. For more information, see [Catalogs and Services](../provisioning_virtual_machines_and_hosts/index.html#catalogs-and-services).
 
 #### Executing an Ansible Tower Job Using a Custom Automate Button
-{: #executing_ansible_tower_job_using_custom_automate_button}
 
 {{ site.data.product.title_short }} can execute Ansible Tower jobs on virtual machines or instances using custom buttons in Automate.
 

managing_providers/_topics/image_import.md

@@ -1,21 +1,17 @@
 # Image Import Workflows
-{: #image_import_workflows}
 
 ## IBM PowerVC to IBM Power Systems Virtual Server
-{: #powervc_to_power_systems_virtual_server}
 
 The image import functionality allows you to easily move an image from your on-prem PowerVC environment to an off-prem Power Systems Virtual Server environment using {{ site.data.product.title_short }} web interface. The enablement of the workflow in {{ site.data.product.title_short }} requires you to perform certain preparations that are described in detail below.
 
 ### Preparing {{ site.data.product.title_short }} hosting server (required once):
-{: #preparing_hosting_server}
 
 The following commands are to be run on a server (or in a corresponding docker container) that is dedicated to hosting your {{ site.data.product.title_short }} instance.
 
 1. Install `ansible-runner` application using the installation [instructions](https://ansible-runner.readthedocs.io/en/stable/install.html). The application must be available in the the command line of the user under which the {{ site.data.product.title_short }} web-server is running.
 
 
 ### Preparing IBM PowerVC Server (required once):
-{: #preparing_powervc_server}
 
 The following commands are to be run on a PowerVC server that is dedicated to supporting the image import workflow.
 
@@ -99,7 +95,6 @@ The following commands are to be run on a PowerVC server that is dedicated to su
         rm /home/sessions/image.ova
 
 ### Add a Cloud Object Storage provider in {{ site.data.product.title_short }}:
-{: #add_cloud_object_storage_provider}
 
 1. See the corresponding instructions [here](storage_providers/ibm_cloud_object_storage_managers.html).
 
@@ -111,12 +106,10 @@ The following commands are to be run on a PowerVC server that is dedicated to su
    **NOTE**: The "root" user as well as the workflow dedicated user of the PowerVC server from step [5](#preparing-ibm-powervc-server-required-once) would both be able to decrypt the Cloud Object Storage's credentials during the execution of the import workflow and therefore make sure to take this into consideration in your security setup.
 
 ### Add an IBM Power Systems Virtual Server provider in {{ site.data.product.title_short }}:
-{: #add_power_systems_virtual_server_provider}
 
 1. See the corresponding instructions [here](cloud_providers/ibm_power_systems_virtual_servers_providers.html).
 
 ### Add an IBM PowerVC provider in {{ site.data.product.title_short }}:
-{: #add_powervc_provider}
 
 1. See the corresponding instructions [here](cloud_providers/ibm_power_vc_providers.html).
 
@@ -129,20 +122,17 @@ The following commands are to be run on a PowerVC server that is dedicated to su
 
 
 ### Grant Image Import Permissions in {{ site.data.product.title_short }}:
-{: #grant_image_import_permissions}
 
 User performing image import needs a corresponding permission in {{ site.data.product.title_short }} in order to perform this operation. For granting permissions, log-in through an administrative account and navigate to `Settings -> Application Settings -> Access Control`. Make sure the user of your choice has permissions for `Import Cloud Template` action through the user's corresponding group and role.
 ![import_access_control](../images/import_access_control.png)
 
 ### Enable Embedded Ansible in {{ site.data.product.title_short }}:
-{: #enable_embedded_ansible}
 
 Currently the workflow event is queued as Embedded Ansible playbook upon request submission and as such the corresponding functionality has to be enabled in {{ site.data.product.title_short }} by navigating to: `Settings -> Application Settings -> Settings`
 
 ![Enable Embedded Ansible](../images/import_emb_ansible.png)
 
 ### Start the workflow
-{: #start_the_workflow}
 
 The workflow operates by exporting the image as an OVA file onto a PowerVC local storage, uploading it to the Cloud Object Storage bucket and then transferring it into Power Systems Virtual Server image registry. In order to initiate the workflow:
 
@@ -180,7 +170,6 @@ The workflow operates by exporting the image as an OVA file onto a PowerVC local
 14. Initiate the refreshing of the Power Systems Virtual Server provider upon workflow completion and wait for the newly imported image to appear.
 
 ### Troubleshooting
-{: #troubleshooting}
 
 * If the {{site.data.product.title_short}} UI shows no detailed error description then make sure to check the latest logs with `journalctl -t evm` or `oc logs` on a server or pod that hosts your {{site.data.product.title_short}} instance.
 

managing_providers/_topics/manageiq-automate-role.md

@@ -1,5 +1,4 @@
 ### Modifying the Automate Workspace Using the `manageiq-automate` Role.
-{: #modifying_automate_workspace_using_manageiq_automate_role}
 
 The `manageiq-automate` role allows users of {{ site.data.product.title_short }} Automate to modify and add to the automate workspace via an Ansible playbook.
 
@@ -11,7 +10,6 @@ The `manageiq-automate` role allows users of {{ site.data.product.title_short }}
 {{ site.data.product.title_short }} will automatically install the role once it sees the `requirements.yml` file in the playbook.
 
 #### Role Variables
-{: #role_variables}
 
 The `manageiq_automate` role employs the following variables when implemented in a playbook run on a {{ site.data.product.title_short }} appliance. Variables are defined in `defaults/main.yml` and `vars/main.yml`.
 
@@ -20,7 +18,6 @@ The `manageiq_automate` role employs the following variables when implemented in
 `manageiq_validate_certs`: By default is set to `True`. If passed in with `extra_vars` or assigned in the playbook variables then the lookup allows self-signed certificates to be used when using SSL REST API connection URLs.
 
 #### Example Playbook
-{: #example_playbook}
 
 The following example utilizes the `manageiq-automate` role. Using variable substitution, playbook tasks retrieve method parameters which are then used to modify object attributes. A final task uses the `set_retry` module to update the retry interval.
 

managing_providers/index.md

@@ -2,7 +2,6 @@
 ---
 
 # Managing Providers
-{: #managing_providers}
 
 {{ site.data.product.title_short }} can manage a variety of external environments, which are known as providers and managers. A provider or manager is any system that {{ site.data.product.title_short }} integrates with for the purpose of collecting data and performing operations.
 
@@ -49,6 +48,5 @@ For information on working with the resources that are contained by a provider o
 {% include_relative _topics/storage_providers.md %}
 
 ## Appendix
-{: #appendix}
 
 {% include app-self_signed_ca.md %}