Bug 1563867 - [RFE] Need safer way to control which hosts are used for running an Ansible Job Template from CloudForms. [NEEDINFO]
Summary: [RFE] Need safer way to control which hosts are used for running an Ansible J...
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.0
Assignee: Alexander Zagaynov
QA Contact: Nandini Chandra
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-04 23:56 UTC by Jeffrey Cutter
Modified: 2021-09-09 13:36 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-02-07 23:01:30 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
gmccullo: needinfo? (cruffalo)
gmccullo: needinfo? (cruffalo)

Attachments (Terms of Use)
Uninformative last message field (85.44 KB, image/png)
2018-08-16 11:06 UTC, Alexander Zagaynov
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0212 0 None None None 2019-02-07 23:01:35 UTC

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.


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

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.


Note You need to log in before you can comment on or make changes to this bug.