Feature Overview

• ACM Create a Service Catalog in Ansible Controller to Consume RHACM.
• In a first step we need an Ansible-Collection for RHACM. Based on this a Service Catalog can be created

      Further Details:

• As Ansible has already collections for many other IT systems and Applications it will become possible to gather facts (parameters) from one system like ServiceNow, inject it during the deployment of a new Cluster via ACM, update the network firewall if required and update the CMDB etc....  Also, it will be very useful for augmenting CI/CD pipeline when not everything is on OCP.
• One other important item is a to have a dynamic inventory for ACM = Capability for Ansible to collect inventory from ACM to gather facts like DNS Name, tags etc... Every time a job will be executed from Controller, it will gather in real time the data requires to run properly the automation.. of course, you can select a specific host you need. 
• So, if we have a collection and the dynamic inventory,  customer will be able to create automation jobs including ACM and this will be available from Catalog (on premise catalogue is due to Summit 2022), from Controller API, from any events that call Controller API..For very large customers who automated all their IT Processes that will be a must have..

Example Usecase

• customers can go to ServiceNow to request a new Cluster  (if they have ServiceNow as ITSM).

           then Ansible is called to for example:

           1 - prepare the underlying infra to receive OCP
           2 - call ACM to deploy OCP
           3 - configure the network or configure some Security systems (if needed)
           4 - auto generate policies using ACM Policy Generator to ensure  automation implemented using Ansible playbook 
           5 - validate OCP is up and running
           6 - if required validate an application is up on running in OCP
           7 - if required configure other systems like a DB
           8 - update ServiceNow job is done + CMDB
 

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>