Bug 1857674

Summary:	Unable to use playbook that requires escalation of priviledge with dialog that incorporates a selection of machine credentials even if "none" is the selected option
Product:	Red Hat CloudForms Management Engine	Reporter:	Felix Dewaleyne <fdewaley>
Component:	Embedded Ansible	Assignee:	William Fitzgerald <wfitzger>
Status:	CLOSED NOTABUG	QA Contact:	Sudhir Mallamprabhakara <smallamp>
Severity:	high	Docs Contact:	Red Hat CloudForms Documentation <cloudforms-docs>
Priority:	medium
Version:	5.11.6	CC:	dmetzger, fdewaley, nlamuro, obarenbo, tfitzger, wfitzger
Target Milestone:	GA
Target Release:	5.11.z
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-08-18 15:52:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	Bug
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	CFME Core	Target Upstream Version:
Embargoed:

Description Felix Dewaleyne 2020-07-16 10:32:51 UTC

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. create a dialog that will use the playbook, but features a "machine redentials" element
4. attempt to use the dialog and template, selecting "none" for the machine credential in this dialog.

Actual results:
ansible playbook is running and in /tmp logs show that it is waiting on a password despite machine credential selection being "none"

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



Additional info:
if you remove the machine credential part of the dialog the playbook runs as expected and the password is passed to ansible.

example of a playbook requiring escalation would be a "yum install bash"

this issue was discovered thanks to https://bugzilla.redhat.com/show_bug.cgi?id=1846621#c28

Comment 5 Nick LaMuro 2020-07-16 16:40:31 UTC

Of note, while the component for this one is set as `Embedded Ansible`, the issue is a dialog issue that happens before the core functionality of EmbeddedAnsible is even invoked and prevents the credential record from being assigned to the playbook instance record.

This means that the proper credential information isn't available at playbook runtime causing it to seem like an issue with the `ansible-runner` execution, when it fact it was working as expected and failed do to not being given the proper data.

-Nick

Comment 6 Felix Dewaleyne 2020-07-17 08:38:13 UTC

Further information to create the dialog :

  - create a new service catalog item of type "Ansible Playbook" using embedded ansible.
  - Under "Dialog", choose "Create new"
  - Complete the remaining of the required fields, and save.

The customer has reported never using the machine credentials selection dropdown as he instead always sets the credential required for the playbook in the Service Catalog Item. He always hide the machine credentials dropdown in the dialog to prevent endusers from overriding the configured machine credential.

Comment 13 Felix Dewaleyne 2020-08-17 11:24:11 UTC

the customer isn't keeping the case open, the workaround of removing the field from the dialog is enough for him (and he has a lot of other issues open).

Comment 14 William Fitzgerald 2020-08-17 14:35:55 UTC

Felix,

Can we close this?

Thanks

Billy

Comment 15 Felix Dewaleyne 2020-08-18 09:01:28 UTC

(In reply to William Fitzgerald from comment #14)
> Felix,
> 
> Can we close this?
> 
> Thanks
> 
> Billy

they are happy with the workaround, so unless there is a bug to fix...  and since we didn't reproduce because of their usage... I think closing and using https://access.redhat.com/solutions/5316621 to cover for this issue should anyone run into it might do it.

should we mark this comment and the last two as public? I default to private.

Comment 16 William Fitzgerald 2020-08-18 15:52:20 UTC

Closing ticket