Bug 1634755 - [RFE] Add smart parameters alike feature to Ansible integration
Summary: [RFE] Add smart parameters alike feature to Ansible integration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Ansible
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: 6.6.0
Assignee: Daniel Lobato Garcia
QA Contact: Lukas Pramuk
URL:
Whiteboard:
: 1649763 1672731 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-01 14:30 UTC by Eric Lavarde
Modified: 2019-10-22 12:47 UTC (History)
7 users (show)

Fixed In Version: tfm-rubygem-foreman_ansible-2.3.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-22 12:46:44 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 24362 Normal Closed Ansible Variables can be imported as LookupKeys 2020-01-17 16:16:55 UTC
Red Hat Product Errata RHSA-2019:3172 None None None 2019-10-22 12:47:07 UTC

Description Eric Lavarde 2018-10-01 14:30:41 UTC
Description of problem:

Satellite discovers applicable parameters to Puppet modules whereas you need to know the parameters applicable to a certain Ansible role and there is no validation.

Version-Release number of selected component (if applicable):
6.4 and beyond

How reproducible:
always

Steps to Reproduce:

1. import an Ansible role

Actual results:

no smart parameters, admin needs to create the parameters manually and they are all of type string

Expected results:

Like for Puppet modules, pre-defined parameters appear.

Additional info:

- Ansible roles are not classes with well defined parameters like Puppet modules hence it's a bit more tricky to address
- _but_ there is a strong convention that parameters are documented (with default value) in the `defaults/main.yml` file.
- the type of the parameters could be derived from the default value _or_ (and I'm not even sure it's a good idea) explicitly entered using YAML types http://yaml.org/type/index.html
- one quirk of the current smart parameters should be also addressed: they appear in a specific CV version / life cycle environment, but it should be possible to pre-fill them in upcoming lce before the module / role applies to it.

Comment 1 Ondřej Pražák 2018-11-09 14:59:39 UTC
Connecting redmine issue https://projects.theforeman.org/issues/24362 from this bug

Comment 2 pm-sat@redhat.com 2018-11-09 15:08:09 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24362 has been resolved.

Comment 3 Bryan Kearney 2018-11-14 13:44:15 UTC
*** Bug 1649763 has been marked as a duplicate of this bug. ***

Comment 4 Marek Hulan 2019-02-28 15:52:52 UTC
the type can't be reliably detected as of now, but all the rest should be addressed in upstream by now

Comment 5 Marek Hulan 2019-05-24 19:27:58 UTC
*** Bug 1672731 has been marked as a duplicate of this bug. ***

Comment 7 Lukas Pramuk 2019-08-08 16:41:52 UTC
VERIFIED.

@Satellite-6.6.0 Snap14
tfm-rubygem-foreman_ansible-3.0.3-3.el7sat.noarch
tfm-rubygem-foreman_ansible_core-3.0.0-1.el7sat.noarch
ansible-2.8.3-1.el7ae.noarch

The RFE was overall tested.
The example of such testing can be illustrated by the following steps
(the steps were performed both CLI and UI):

# ansible-galaxy install -p /etc/ansible/roles linuxhq.setup

# hammer ansible roles import --proxy-id 1

# hammer ansible variables import --proxy-id 1
Result:   
  The following ansible variables were changed
Imported: 
 1) setup_aliases
 2) setup_environment
 3) setup_hosts
 4) setup_hostname
 5) setup_motd
 6) setup_profile_d
 7) setup_securetty
 8) setup_shells
... 

>>> ansible variables imported successfully

# hammer ansible variables delete --name setup_aliases
Ansible variable [setup_aliases] was deleted.

# hammer ansible variables import --proxy-id 1
Result:   
  The following ansible variables were changed
Imported: 
 1) setup_aliases

>>> variable re-imported successfully

# hammer ansible variables create --variable custom_var --variable-type yaml --ansible-role linuxhq.setup
Ansible variable [custom_var] was created.

>>> custom variable created successfully

# hammer ansible variables update --name setup_motd --default-value $(base64 <<< 'Hello world') --override yes
Ansible variable [setup_motd] updated.

>>> ansible variable overridden successfully 

# hammer host ansible-roles assign --name $(hostname) --ansible-roles linuxhq.setup
Ansible roles were assigned to the host

# hammer host ansible-roles play --name $(hostname)
Ansible roles are being played. Job ID: 3

# hammer job-invocation output --id 3 --host $(hostname)
...
changed: [<HOST_FQDN>] => (item=motd)
...
Exit status: 0

# cat /etc/motd
Hello world

>>> overridden ansible variable gets applied to the host successfully

Comment 9 errata-xmlrpc 2019-10-22 12:46:44 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:3172


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