Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2000141 - User data provisioning template does not render correctly for the first boot
Summary: User data provisioning template does not render correctly for the first boot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Provisioning Templates
Version: 6.10.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: sganar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-01 13:47 UTC by Ondrej Gajdusek
Modified: 2022-10-28 18:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-28 18:06:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
user-data.txt (3.15 KB, text/plain)
2021-09-02 15:17 UTC, Ondrej Gajdusek
no flags Details
user-data-rendered-by-satellite.txt (3.35 KB, text/plain)
2021-09-02 15:19 UTC, Ondrej Gajdusek
no flags Details
anonymized-host-detail.txt (2.02 KB, text/plain)
2021-09-02 15:20 UTC, Ondrej Gajdusek
no flags Details

Description Ondrej Gajdusek 2021-09-01 13:47:08 UTC
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.

Comment 1 Marek Hulan 2021-09-02 07:24:08 UTC
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?

Comment 2 Ondrej Gajdusek 2021-09-02 15:17:03 UTC
Created attachment 1820067 [details]
user-data.txt

Anonymized User data file from the provisioned host - /var/lib/cloud/instance/user-data.txt

Comment 3 Ondrej Gajdusek 2021-09-02 15:19:28 UTC
Created attachment 1820068 [details]
user-data-rendered-by-satellite.txt

Anonymized User data file rendered by Satellite after the host is provisioned.

Comment 4 Ondrej Gajdusek 2021-09-02 15:20:47 UTC
Created attachment 1820069 [details]
anonymized-host-detail.txt

Hammer output of the host detail.

Comment 5 Ondrej Gajdusek 2021-09-02 15:27:03 UTC
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

Comment 6 Brad Buckingham 2021-09-09 14:05:47 UTC
Is this a regression from Satellite 6.9?

Comment 7 Ondrej Gajdusek 2021-09-09 15:43:29 UTC
This is not a regression from Satellite 6.9. You can find the exact behavior there too.

Comment 8 Lukas Zapletal 2021-09-21 07:53:48 UTC
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.)

Comment 10 Brad Buckingham 2022-09-02 20:25:18 UTC
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.

Comment 11 Brad Buckingham 2022-09-02 20:31:26 UTC
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.

Comment 12 Brad Buckingham 2022-10-28 18:06:36 UTC
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.


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