Bug 1757391

Summary: No way of limiting AE Method type "Ansible Tower Job Template"
Product: Red Hat CloudForms Management Engine Reporter: mplesko
Component: AutomateAssignee: Tina Fitzgerald <tfitzger>
Status: CLOSED DUPLICATE QA Contact: Nandini Chandra <nachandr>
Severity: medium Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: medium    
Version: 5.12.0CC: akarol, dmetzger, gmccullo, mkanoor, obarenbo
Target Milestone: GAFlags: mfeifer: mirror+
Target Release: 5.12.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-01 13:51:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Bug
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: Ansible Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshots none

Description mplesko 2019-10-01 11:44:35 UTC
Created attachment 1621379 [details]
Screenshots

Description of problem: I can create and use AE Method of type "Ansible Tower Job Template" but it'll always run against ENTIRE CloudForms inventory i.e. against all VMs of all providers.


Version-Release number of selected component (if applicable):
5.11.0.24

How reproducible:
Always

Steps to Reproduce:
1. In Automate > Explorer navigate to arbitrary AE Class and open tab "Methods"
2. Add a new method of type "Ansible Tower Job Template" (see screenshot 01 attached)
3. hook method to some AE instance
4. trigger instance

Actual results:
Job Template will run against entire CloudForms inventory!

Expected results:
User should be able to limit run to specific subset of the CloudForms inventory. It should be possible to specify the subset both:
- in a hard-coded way (sometimes you know your targets upfront)
- in a dynamic way. Subset of hosts should be read from state vars (because sometimes previous steps of the state machine create a new VM so the IP is not known upfront)

Additional info:

Comment 3 dmetzger 2019-10-01 13:51:30 UTC

*** This bug has been marked as a duplicate of bug 1757190 ***