Bug 1846621

Summary: using escalate privilage causes playbooks to get stuck waiting for a password
Product: Red Hat CloudForms Management Engine Reporter: Felix Dewaleyne <fdewaley>
Component: Embedded AnsibleAssignee: William Fitzgerald <wfitzger>
Status: CLOSED NOTABUG QA Contact: Gaurav Talreja <gtalreja>
Severity: high Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: high    
Version: 5.11.5CC: dmetzger, fdewaley, gtalreja, nlamuro, sigbjorn.lie, wfitzger
Target Milestone: GA   
Target Release: 5.11.8   
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: 2020-07-16 17:15:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:
Attachments:
Description Flags
behaviour.txt none

Description Felix Dewaleyne 2020-06-12 10:11:19 UTC 
Created attachment 1696994 [details]
behaviour.txt

Created attachment 1696994 [details]
behaviour.txt

Description of problem:
Ansible Playbooks with Escalate Privilege=Yes get stuck and end up in error after upgrade to 5.0

Version-Release number of selected component (if applicable):
5.11.7
ansible runner.

How reproducible:
all the time in customer environment

Steps to Reproduce:
1. create a playbook that requires escalation privilege to work
2. set up playbook with "escalate priviledge yes"
3.

Actual results:
ansible playbook is running and in /tmp logs show that it is waiting on a password.

Expected results:
the playbook does not get stuck on the password input

Additional info:
Comment 16 Nick LaMuro 2020-06-16 22:41:31 UTC 
I have provided a fix a possible fix for this bug here:

https://github.com/ManageIQ/manageiq/pull/20282
Comment 37 Nick LaMuro 2020-07-16 17:15:21 UTC 
The core issue that prompted this BZ is now being handled in https://bugzilla.redhat.com/show_bug.cgi?id=1857674 and it was found there was no issue when the credential was being passed in properly to EmbeddedAnsible.

Closing as NOTABUG any issues that came out of this BZ are being handled in followup tickets.