Description of problem: Cloud-init customisation templates are not applied. Version-Release number of selected component (if applicable): cfme-vsphere-5.6.0.6-1.x86_64.vsphere.ova How reproducible: Provision Linux workload from private template, se Steps to Reproduce: 1. Select private Linux template which has cloud-init installed 2. Compute > Clouds > Instances > Provision Instance > [select image] 3. Complete provisioning dialogues 4. Select cloud-init customisation template Actual results: Customisation template is not applied. Expected results: Customisation template applied. Additional info: Reviewing /var/lib/waagent/ovf-env.xml on the deployed instance, customdata is present. <ns1:CustomData>STJOc2IzVmtMV052Ym1acFp3cDNjbWwwWlY5bWFXeGxjem9LSUNBdElIQmhkR2c2SUM5MFpYTjBMblI0CmRBb2dJQ0FnWTI5dWRHVnVkRG9nZkFvZ0lDQWdJQ0JJWlhKbElHbHpJR0VnYkdsdVpTNEtJQ0FnSUNBZwpRVzV2ZEdobGNpQnNhVzVsSUdseklHaGxjbVV1Cg==</ns1:CustomData> However, it is decoded twice: Base64.decode64(Base64.decode64(s)) => "#cloud-config\nwrite_files:\n - path: /test.txt\n content: |\n Here is a line.\n Another line is here." Looking at app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb, the custom_data function is encoding an already encoded value. Here is a suggested fix: def custom_data # Base64.encode64(userdata_payload.encode("UTF-8")).delete("\n") userdata_payload.delete("\n") end
PR submitted: https://github.com/ManageIQ/manageiq/pull/8686
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/14d7de3db05916a51b0b97cb01c3dd1ed2fb8d12 commit 14d7de3db05916a51b0b97cb01c3dd1ed2fb8d12 Author: Daniel Berger <dberger> AuthorDate: Fri May 13 07:42:11 2016 -0600 Commit: Daniel Berger <dberger> CommitDate: Fri May 13 13:33:08 2016 -0600 Don't double encode customdata when provisioning an Azure VM. https://bugzilla.redhat.com/show_bug.cgi?id=1335895 app/models/manageiq/providers/azure/cloud_manager/provision/cloning.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I'm going to need some help on this one when you find some time. This is my 5.6.0.8 LTS appliance - https://10.16.6.195 I'll find a 30 minute slot on your calendar.
Seems to be working fine on https://10.16.7.233 which runs 5609. Given the obvious nature of the changed code, I'm going to move it to verified.
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/RHBA-2016:1348