Bug 1563867

Summary:

[RFE] Need safer way to control which hosts are used for running an Ansible Job Template from CloudForms.

Product:

Red Hat CloudForms Management Engine

Reporter:

Jeffrey Cutter <jcutter>

Component:

Automate

Assignee:

Alexander Zagaynov <azagayno>

Status:

CLOSED ERRATA

QA Contact:

Nandini Chandra <nachandr>

Severity:

medium

Docs Contact:

Priority:

high

Version:

5.9.0

CC:

akarol, azagayno, bilwei, brant.evans, cruffalo, dmisharo, gekis, mkanoor, obarenbo, pmcgowan, simaishi, smallamp, tfitzger

Target Milestone:

Keywords:

FutureFeature

Target Release:

5.10.0

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

5.10.0.15

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2019-02-07 23:01:30 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Uninformative last message field	none

Description Jeffrey Cutter 2018-04-04 23:56:27 UTC

This has been a concern of mine and various other Consultants I have spoken to.  As is defined in BZ 1504231, if the Prompt on Launch check box for Limit is not checked in the Tower Job Template, the Job gets run without the limit.  This is a common error I have seen repeatedly and one that could have catastrophic consequences if the wrong playbook got ran against the wrong inventory without the limit in place.  In my estimation it's a disaster looking for a place to happen and improving the documentation does not do the issue justice when you consider how much damage could be done.

An option I've seen used which I picked up from my teammates to avoid this possibility is to use an extra_var to define the hosts for the playbook, for example, in the playbook:

  hosts: "{{ target_hostname }}"

And in the Job Template instance in CloudForms define an extra_var for target_hostname=hostname.example.com.

In this manner, if the box is not checked as it should be the worse thing that happens is the playbook fails to run.

Thanks,
-Jeff

Comment 2 Chris Ruffalo 2018-04-05 01:10:05 UTC

I'd like to add that there seems to be quite a few easy ways to mess up and get yourself in a situation where the limit value is not getting passed all the way through.

In my case it was missing the proper service bundle entry point in the ROLE online training.

Running a playbook in an environment against the entire inventory instead of a limited group of hosts is a particularly startling way to be reminded you've set it up wrong.

Comment 3 Greg McCullough 2018-07-31 16:15:22 UTC

To clarify, by having the wrong entry-point you are running into an issue because I dialog field is not being passed down to sub-service provision, is that correct?

I see two distinct problems here:
1. A limit value is passed but the JobTemplate will ignore it because "Prompt on Launch" is not checked.  We should be able to easily validate this right before launching the the JobTemplate in the ansible_tower_client_gem.

2) An empty limit value is specified when a value was expected.  This is a configuration error and there is no way for us to auto-detect when limit is required.  In this case it seems we would need an additional parameter that we track internally to prevent a JobTemplate for running without a limit.  It would be on the admin to properly mark the JobTemplates that require it.

For #2, without back-end code changes you could prevent this by creating a tag for this purpose and adding logic to the automate method to validate before running.

Comment 4 Greg McCullough 2018-08-01 13:35:11 UTC

Setting High priority per bascar.

Comment 5 Greg McCullough 2018-08-01 14:19:22 UTC

As I think I understand your use case now and as described in comment #3 I am asking that you open a separate BZ on the issue you are raising.

As described above it is the same end result but completely different paths to recreate and ultimately different solutions to resolve.  I would like to keep this issue for solving item #1.

Comment 7 Alexander Zagaynov 2018-08-16 11:06:19 UTC

Created attachment 1476405 [details]
Uninformative last message field

PR: https://github.com/ansible/ansible_tower_client_ruby/pull/119

However, as you can see on the picture, user will not be able to see error reason.

Comment 8 Alexander Zagaynov 2018-09-13 14:36:48 UTC

PR merged

Comment 9 Nandini Chandra 2019-01-29 19:36:25 UTC

Reproducer steps:

1)In an external Ansible tower,create a job template with an inventory containing more than one host. Make sure the PROMPT ON LAUNCH check box for limit is not checked.
2)In CFME, add the Tower as a provider and create a catalog item based on the job template and apply limit to one of the hosts in the inventory.

Without the fix, the limit option is ignored, the playbook runs on all hosts in the inventory.
With the fix, the service ordering fails with this error message: 'PROMPT ON LAUNCH' is required for the following fields: limit

Here's the error message logged to automation.log:
ter: nil, tenant_id: 1, ancestry: nil, initiator: "user">>
[----] E, [2019-01-29T14:21:20.894134 #60406:b5dfec0] ERROR -- : Q-task_id([r7_service_template_provision_task_9]) MiqAeServiceModelBase.ar_method raised: <MiqException::MiqOrchestrationProvisionError>: <'PROMPT ON LAUNCH' is required for the following fields: limit>

Verified in 5.10.0.32

Comment 11 errata-xmlrpc 2019-02-07 23:01:30 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:0212

Comment 12 Red Hat Bugzilla 2023-09-15 00:07:23 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days