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.
Connecting redmine issue https://projects.theforeman.org/issues/24362 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24362 has been resolved.
*** Bug 1649763 has been marked as a duplicate of this bug. ***
the type can't be reliably detected as of now, but all the rest should be addressed in upstream by now
*** Bug 1672731 has been marked as a duplicate of this bug. ***
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
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