ansible · EMcWhinn · May 20, 2025 · May 20, 2025
diff --git a/downstream/assemblies/platform/assembly-UG-overview.adoc b/downstream/assemblies/platform/assembly-UG-overview.adoc
@@ -4,16 +4,56 @@ ifdef::context[:parent-context: {context}]
 = {ControllerNameStart} overview
 
 :context: overview-controller
+:mod-docs-content-type: <ASSEMBLY>
 
 With {PlatformNameShort} users across an organization can share, vet, and manage automation content by means of a simple, powerful, and agentless technical implementation. 
 IT managers can provide guidelines on how automation is applied to individual teams. 
 Automation developers can write tasks that use existing knowledge, without the operational overhead of conforming to complex tools and frameworks. 
 It is a more secure and stable foundation for deploying end-to-end automation solutions, from hybrid cloud to the edge.
 
-{PlatformNameShort} includes {ControllerName}, which enables users to define, operate, scale, and delegate automation across their enterprise.
-
 include::platform/con-controller-overview-details.adoc[leveloffset=+1]
 
+include::platform/con-controller-overview-exploration.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-automation.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-rbac.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-cloud-autoscaling.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-api.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-backup-restore.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-galaxy.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-openstack.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-remote-exec.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-tracking.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-notifiers.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-integrations.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-virtual-envs.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-auth-enhance.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-cluster-manage.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-workflow-enhancements.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-job-distribution.adoc[leveloffset=+1]
+
+include::platform/con-controller-fips-support.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-host-limits.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-inventory-plugins.adoc[leveloffset=+1]
+
+include::platform/con-controller-overview-secret-management.adoc[leveloffset=+1]
 
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/downstream/modules/platform/con-controller-fips-support.adoc b/downstream/modules/platform/con-controller-fips-support.adoc
@@ -0,0 +1,6 @@
+[id="con-controller-fips-support_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Support for deployment in a FIPS-enabled environment
+{ControllerNameStart} deploys and runs in restricted modes such as FIPS.
diff --git a/downstream/modules/platform/con-controller-overview-api.adoc b/downstream/modules/platform/con-controller-overview-api.adoc
@@ -0,0 +1,6 @@
+
+:mod-docs-content-type: <CONCEPT>
+
+= The ideal RESTful API
+The {ControllerName} REST API is the ideal RESTful API for a systems management application, with all resources fully discoverable, paginated, searchable, and well modeled. A styled API browser enables API exploration from the API root at `\http://<server name>/api/`, showing off every resource and relation. Everything that can be done in the user interface can be done in the API.
diff --git a/downstream/modules/platform/con-controller-overview-auth-enhance.adoc b/downstream/modules/platform/con-controller-overview-auth-enhance.adoc
@@ -0,0 +1,14 @@
+[id="con-controller-overview-auth-enhance_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Authentication enhancements
+{ControllerNameStart} supports:
+
+* LDAP
+* SAML
+* token-based authentication
+
+With LDAP and SAML support you can integrate your enterprise account information in a more flexible manner.
+
+Token-based authentication permits authentication of third-party tools and services with {ControllerName} through integrated OAuth 2 token support.
diff --git a/downstream/modules/platform/con-controller-overview-automation.adoc b/downstream/modules/platform/con-controller-overview-automation.adoc
@@ -0,0 +1,7 @@
+[id="con-controller-overview-automation_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= "Push Button" automation
+Use {ControllerName} to access your favorite projects and re-trigger execution from the web interface.
+{ControllerNameStart} asks for input variables, prompts for your credentials, starts and monitors jobs, and displays results and host history.
diff --git a/downstream/modules/platform/con-controller-overview-backup-restore.adoc b/downstream/modules/platform/con-controller-overview-backup-restore.adoc
@@ -0,0 +1,6 @@
+[id="con-controller-overview-backup-restore_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Backup and restore
+{PlatformNameShort} can backup and restore your systems or systems, making it easy for you to backup and replicate your instance as required.
diff --git a/downstream/modules/platform/con-controller-overview-cloud-autoscaling.adoc b/downstream/modules/platform/con-controller-overview-cloud-autoscaling.adoc
@@ -0,0 +1,12 @@
+[id="con-controller-overview-cloud-autoscaling_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Cloud and autoscaling flexibility
+{ControllerNameStart} includes a powerful optional provisioning callback feature that enables nodes to request configuration on-demand.
+This is an ideal solution for a cloud auto-scaling scenario and includes the following features:
+
+* It integrates with provisioning servers such as Cobbler and deals with managed systems with unpredictable uptimes.
+* It requires no management software to be installed on remote nodes.
+* The callback solution can be triggered by a call to `curl` or `wget`, and can be embedded in `init` scripts, kickstarts, or preseeds.
+* You can control access so that only machines listed in the inventory can request configuration.
diff --git a/downstream/modules/platform/con-controller-overview-cluster-manage.adoc b/downstream/modules/platform/con-controller-overview-cluster-manage.adoc
@@ -0,0 +1,6 @@
+[id="con-controller-overview-cluster-manage_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Cluster management
+Run time management of cluster groups enables configurable scaling.
diff --git a/downstream/modules/platform/con-controller-overview-details.adoc b/downstream/modules/platform/con-controller-overview-details.adoc
@@ -1,162 +1,5 @@
-[id="con-controller-overview-details"]
+[id="con-controller-overview-details_{context}"]
 
-= Real-time playbook output and exploration
-With {ControllerName} you can watch playbooks run in real time, seeing each host as they check in.
-You can go back and explore the results for specific tasks and hosts in great detail, search for specific plays or hosts and see just those results, or locate errors that need to be corrected.
+:mod-docs-content-type: <CONCEPT>
 
-= "Push Button" automation
-Use {ControllerName} to access your favorite projects and re-trigger execution from the web interface.
-{ControllerNameStart} asks for input variables, prompts for your credentials, starts and monitors jobs, and displays results and host history.
-
-= Simplified role-based access control and auditing
-With {ControllerName} you can:
-
-* Grant permissions to perform a specific task to different teams or explicit users through _role-based access control_ (RBAC).
-Example tasks include viewing, creating, or modifying a file.
-* Keep some projects private, while enabling some users to edit inventories, and others to run playbooks against certain systems, either in check (dry run) or live mode.
-* Enable certain users to use credentials without exposing the credentials to them.
-
-{ControllerNameStart} records the history of operations and who made them, including objects edited and jobs launched.
-
-If you want to give any user or team permissions to use a job template, you can assign permissions directly on the job template. Credentials are full objects in the {ControllerName} RBAC system, and can be assigned to many users or teams for use.
-
-{ControllerNameStart} includes an _auditor_ type. A system-level auditor can see all aspects of the systems automation, but does not have permission to run or change automation.
-An auditor is useful for a service account that scrapes automation information from the REST API.
-
-.Additional resources
-
-= Cloud and autoscaling flexibility
-{ControllerNameStart} includes a powerful optional provisioning callback feature that enables nodes to request configuration on-demand.
-This is an ideal solution for a cloud auto-scaling scenario and includes the following features:
-
-* It integrates with provisioning servers such as Cobbler and deals with managed systems with unpredictable uptimes.
-* It requires no management software to be installed on remote nodes.
-* The callback solution can be triggered by a call to `curl` or `wget`, and can be embedded in `init` scripts, kickstarts, or preseeds.
-* You can control access so that only machines listed in the inventory can request configuration.
-
-= The ideal RESTful API
-The {ControllerName} REST API is the ideal RESTful API for a systems management application, with all resources fully discoverable, paginated, searchable, and well modeled. A styled API browser enables API exploration from the API root at `\http://<server name>/api/`, showing off every resource and relation. Everything that can be done in the user interface can be done in the API.
-
-= Backup and restore
-{PlatformNameShort} can backup and restore your systems or systems, making it easy for you to backup and replicate your instance as required.
-
-= Ansible Galaxy integration
-By including an {Galaxy} `requirements.yml` file in your project directory, {ControllerName} automatically fetches the roles your playbook needs from Galaxy, GitHub, or your local source control.
-For more information, see xref:ref-projects-galaxy-support[Ansible Galaxy Support].
-
-= Inventory support for OpenStack
-Dynamic inventory support is available for OpenStack. With this you can target any of the virtual machines or images running in your OpenStack cloud.
-
-For more information, see xref:ref-controller-credential-openstack[OpenStack credential type].
-
-= Remote command execution
-Use remote command execution to perform a simple task, such as adding a single user, updating a single security vulnerability, or restarting a failing service.
-Any task that you can describe as a single Ansible play can be run on a host or group of hosts in your inventory. 
-You can manage your systems quickly and easily.
-Because of an RBAC engine and detailed audit logging, you know which user has completed a specific task.
-
-= System tracking
-You can collect facts by using the fact caching feature. For more information, see xref:controller-fact-caching[Fact Caching].
-
-= Integrated notifications
-Keep track of the status of your automation.
-
-You can configure the following notifications:
-
-* stackable notifications for job templates, projects, or entire organizations
-* different notifications for job start, job success, job failure, and job approval (for workflow nodes)
-
-The following notification sources are supported:
-
-* xref:controller-notification-email[Email]
-* xref:controller-notification-grafana[Grafana]
-* xref:controller-notification-irc[IRC]
-* xref:controller-notification-mattermost[Mattermost]
-* xref:controller-notification-pagerduty[PagerDuty]
-* xref:controller-notification-rocketchat[Rocket.Chat]
-* xref:controller-notification-slack[Slack]
-* xref:controller-notification-twilio[Twilio]
-* xref:controller-notification-webhook[Webhook] (post to an arbitrary webhook, for integration into other tools)
-
-You can also customize notification messages for each of the preceding notification types.
-
-= Integrations
-
-{ControllerNameStart} supports the following integrations:
-
-* Dynamic inventory sources for Red Hat Satellite 6.
-
-For more information, see xref:proc-controller-inv-source-satellite[Red Hat Satellite 6].
-
-* Red Hat Insights integration, enabling Insights playbooks to be used as an {PlatformNameShort} project.
-
-For more information, see xref:controller-setting-up-insights[Setting up Red Hat Insights for {PlatformName} Remediations].
-
-* {HubNameStart} acts as a content provider for {ControllerName}, requiring both an {ControllerName} deployment and an {HubName} deployment running alongside each other.
-
-
-= Custom Virtual Environments
-With Custom Ansible environment support you can have different Ansible environments and specify custom paths for different teams and jobs.
-
-= Authentication enhancements
-Automation controller supports:
-
-* LDAP
-* SAML
-* token-based authentication
-
-With LDAP and SAML support you can integrate your enterprise account information in a more flexible manner.
-
-Token-based authentication permits authentication of third-party tools and services with {ControllerName} through integrated OAuth 2 token support.
-
-= Cluster management
-Run time management of cluster groups enables configurable scaling.
-
-= Workflow enhancements
-To model your complex provisioning, deployment, and orchestration workflows, you can use {ControllerName} expanded workflows in several ways:
-
-* *Inventory overrides for Workflows* You can override an inventory across a workflow at workflow definition time, or at launch time.
-Use {ControllerName} to define your application deployment workflows, and then re-use them in many environments.
-* *Convergence nodes for Workflows* When modeling complex processes, you must sometimes wait for many steps to finish before proceeding.
-{ControllerNameStart} workflows can replicate this; workflow steps can wait for any number of earlier workflow steps to complete properly before proceeding.
-* *Workflow Nesting* You can re-use individual workflows as components of a larger workflow.
-Examples include combining provisioning and application deployment workflows into a single workflow.
-* *Workflow Pause and Approval* You can build workflows containing approval nodes that require user intervention.
-This makes it possible to pause workflows in between playbooks so that a user can give approval (or denial) for continuing on to the next step in the workflow.
-
-For more information, see xref:controller-workflows[Workflows in {ControllerName}].
-
-= Job distribution
-
-Take a fact gathering or configuration job running across thousands of machines and divide it into slices that can be distributed across your {ControllerName} cluster. 
-This increases reliability, offers faster job completion, and improved cluster use.

-For example, you can change a parameter across 15,000 switches at scale, or gather information across your multi-thousand-node RHEL estate.
-
-For more information, see xref:controller-job-slicing[Job slicing].
-
-= Support for deployment in a FIPS-enabled environment
-{ControllerNameStart} deploys and runs in restricted modes such as FIPS.
-
-= Limit the number of hosts per organization
-Many large organizations have instances shared among many organizations.
-To ensure that one organization cannot use all the licensed hosts, this feature enables superusers to set a specified upper limit on how many licensed hosts can that you can allocate to each organization.
-The {ControllerName} algorithm factors changes in the limit for an organization and the number of total hosts across all organizations.
-Inventory updates fail if an inventory synchronization brings an organization out of compliance with the policy.
-Additionally, superusers are able to over-allocate their licenses, with a warning.
-
-= Inventory plugins
-The following inventory plugins are used from upstream collections:
-
-* `amazon.aws.aws_ec2`
-* `community.vmware.vmware_vm_inventory`
-* `azure.azcollection.azure_rm`
-* `google.cloud.gcp_compute`
-* `theforeman.foreman.foreman`
-* `openstack.cloud.openstack`
-* `ovirt.ovirt.ovirt`
-* `awx.awx.tower`
-
-= Secret management system
-With a secret management system, external credentials are stored and supplied for use in {ControllerName} so you need not provide them directly.
+{PlatformNameShort} includes {ControllerName}, which enables users to define, operate, scale, and delegate automation across their enterprise.
diff --git a/downstream/modules/platform/con-controller-overview-exploration.adoc b/downstream/modules/platform/con-controller-overview-exploration.adoc
@@ -0,0 +1,7 @@
+[id="con-controller-overview-exploration_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Real-time playbook output and exploration
+With {ControllerName} you can watch playbooks run in real time, seeing each host as they check in.
+You can go back and explore the results for specific tasks and hosts in great detail, search for specific plays or hosts and see just those results, or locate errors that need to be corrected.
diff --git a/downstream/modules/platform/con-controller-overview-galaxy.adoc b/downstream/modules/platform/con-controller-overview-galaxy.adoc
@@ -0,0 +1,7 @@
+[id="con-controller-overview-galaxy_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Ansible Galaxy integration
+By including an {Galaxy} `requirements.yml` file in your project directory, {ControllerName} automatically fetches the roles your playbook needs from Galaxy, GitHub, or your local source control.
+For more information, see xref:ref-projects-galaxy-support[Ansible Galaxy Support].
diff --git a/downstream/modules/platform/con-controller-overview-host-limits.adoc b/downstream/modules/platform/con-controller-overview-host-limits.adoc
@@ -0,0 +1,10 @@
+[id="con-controller-overview-host-limits_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Limit the number of hosts per organization
+Many large organizations have instances shared among many organizations.
+To ensure that one organization cannot use all the licensed hosts, this feature enables superusers to set a specified upper limit on how many licensed hosts can that you can allocate to each organization.
+The {ControllerName} algorithm factors changes in the limit for an organization and the number of total hosts across all organizations.
+Inventory updates fail if an inventory synchronization brings an organization out of compliance with the policy.
+Additionally, superusers are able to over-allocate their licenses, with a warning.
diff --git a/downstream/modules/platform/con-controller-overview-integrations.adoc b/downstream/modules/platform/con-controller-overview-integrations.adoc
@@ -0,0 +1,17 @@
+[id="con-controller-overview-integrations_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Integrations
+
+{ControllerNameStart} supports the following integrations:
+
+* Dynamic inventory sources for Red Hat Satellite 6.
+
+For more information, see xref:proc-controller-inv-source-satellite[Red Hat Satellite 6].
+
+* Red Hat Insights integration, enabling Insights playbooks to be used as an {PlatformNameShort} project.
+
+For more information, see xref:controller-setting-up-insights[Setting up Red Hat Insights for {PlatformName} Remediations].
+
+* {HubNameStart} acts as a content provider for {ControllerName}, requiring both an {ControllerName} deployment and an {HubName} deployment running alongside each other.
diff --git a/downstream/modules/platform/con-controller-overview-inventory-plugins.adoc b/downstream/modules/platform/con-controller-overview-inventory-plugins.adoc
@@ -0,0 +1,17 @@
+[id="con-controller-overview-inventory-plugins_{context}"]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Inventory plugins
+The following inventory plugins are used from upstream collections:
+
+* `amazon.aws.aws_ec2`
+* `community.vmware.vmware_vm_inventory`
+// May be one for vmware-exsi?
+* `azure.azcollection.azure_rm`
+* `google.cloud.gcp_compute`
+* `theforeman.foreman.foreman`
+* `openstack.cloud.openstack`
+* `ovirt.ovirt.ovirt`
+* `awx.awx.tower`
+//Possible 3 new plugins.
diff --git a/downstream/modules/platform/con-controller-overview-job-distribution.adoc b/downstream/modules/platform/con-controller-overview-job-distribution.adoc
@@ -0,0 +1,12 @@
+[id=con-controller-overview-job-distribution_{context}]
+
+:mod-docs-content-type: <CONCEPT>
+
+= Job distribution
+
+Take a fact gathering or configuration job running across thousands of machines and divide it into slices that can be distributed across your {ControllerName} cluster. 
+This increases reliability, offers faster job completion, and improved cluster use.
+
+For example, you can change a parameter across 15,000 switches at scale, or gather information across your multi-thousand-node RHEL estate.
+
+For more information, see link:{URLControllerUserGuide}/controller-job-slicing[Job slicing].