Bug 2000141
| Summary: | User data provisioning template does not render correctly for the first boot | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Ondrej Gajdusek <ogajduse> | ||||||||
| Component: | Provisioning Templates | Assignee: | satellite6-bugs <satellite6-bugs> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | sganar | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.10.0 | CC: | lzap, mhulan, sganar | ||||||||
| Target Milestone: | Unspecified | Keywords: | Triaged | ||||||||
| Target Release: | Unused | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-10-28 18:06:36 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Ondrej Gajdusek
2021-09-01 13:47: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? 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. 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. |