Description of problem: The "Kickstart default user data" provisioning template is not rendered correctly at the time when it is passed to the OpenStack compute resource. The Ansible provisioning template snippet is not rendered even if `ansible_tower_provisioning` is set to "true". Version-Release number of selected component (if applicable): Satellite 6.10 foreman-2.5.2.4-1.el7sat.noarch How reproducible: always Steps to Reproduce: 1. Have OSP compute resource configured. 2. Have an OSP image configured and enable "User Data" for this image. 3. Create a new host on OSP without using a host group, use the image that has "User Data" enabled, and set the following parameters for the host. `ansible_tower_provisioning`: true (boolean type) `ansible_host_config_key`: "testvalue" `ansible_job_template_id`: "testvalue" `ansible_tower_fqdn`: "testvalue" Actual results: The host gets provisioned, however, the "User data template" that is pushed to the host is not rendered correctly - the "ansible_tower_callback_script" snippet is not rendered. See /var/lib/cloud/instance/user-data.txt and compare it with the "User data template" from Satellite after the host is provisioned. Expected results: "User data template" matches the /var/lib/cloud/instance/user-data.txt file on the provisioned host. Additional info: The template is rendered correctly if the parameters are present on the host group level instead of on the host level.
Could you be more specific in what is the actual diff? When I look at the template, if ansible_tower_provisioning is true-ish, it should be creating /tmp/ansible_provisioning_call.sh and running it. Could you upload the /var/lib/cloud/instance/user-data.txt? Can you double check your image is set to be using user-data template? The additional info you've added indicates there may be a different problem, in fact it would mean that "host_param_true?" macro does not reflect host parametrization inheritance and only reflects parameters set on host level. But that would affect many more parts like puppet setup, package upgrade, fw settings, ntp confiugration etc. So can you confirm this is the behavior you see? Do we have some automation regarding the parameter values evaluation in templates?
Created attachment 1820067 [details] user-data.txt Anonymized User data file from the provisioned host - /var/lib/cloud/instance/user-data.txt
Created attachment 1820068 [details] user-data-rendered-by-satellite.txt Anonymized User data file rendered by Satellite after the host is provisioned.
Created attachment 1820069 [details] anonymized-host-detail.txt Hammer output of the host detail.
The diff between the two files that I uploaded clearly shows that the ansible_tower_provisioning host parameter is not reflected during the templatization and the rendered template is pushed to OSP. It seems that the problem is exactly what you stated in the second paragraph in comment 1
Is this a regression from Satellite 6.9?
This is not a regression from Satellite 6.9. You can find the exact behavior there too.
Here is the diff: https://www.diffchecker.com/952D4PGL I can confirm Marek's idea - host_param macro use host_param host method which indeed include inheritance: def host_param(param_name, default = nil) check_host host.host_param(param_name) || default end However host_param_true/false helpers were introduced later and they fetch the value directly from the hash def host_param_true?(name, default_value = false) check_host value = host.params.fetch(name, default_value) Foreman::Cast.to_bool(value) == true end (I do not have time to fix this I am just going over BZs.)
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you.
Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.