+++ This bug was initially created as a clone of Bug #1772002 +++ +++ This bug was initially created as a clone of Bug #1771358 +++ Description of problem: The CloudProviderConfig-INI contains truncated values when they contained e.g. the pound character `#`. I honestly would not know how to test vSphere, but the same happened on OpenStack (which was using similar code), as reported in the parent bug.
According to the original bug targeted on openstack. This one should be a synchronous enhancement on vsphere for future proofing. So i will try to reproduce it on v4.3 according to https://github.com/openshift/installer/pull/2686#issuecomment-579285558 Currently QE use the vsphere provided by dpp guy without # special character letter in password. So I have to ask for dev's help here to support on a password update.
@Pierre Prinetti I have a try without real installation run to have a quick reproduce. But it can not reproduce, following are my steps: 1. Edit install-config.yaml to update password to a fake one which include #. # cat demo/install-config.yaml |grep pass password: 'abc#BC' 2. Run "create manifests" to generate manifests. # ./openshift-install create manifests --dir demo INFO Consuming Install Config from target directory 3. Check the password. # cat openshift/99_cloud-creds-secret.yaml |grep pass vcsa-qe.vmware.devcluster.openshift.com.password: YWJjI0JD # echo YWJjI0JD | base64 -d abc#BC The password is not truncated with #. I compared pr#2686 for vsphere and pr#2659 for openstack(https://bugzilla.redhat.com/show_bug.cgi?id=1772002), they are not the same at the password handle. In pr2686, no password changed, just struct change for cloudproviderconfig. So i wonder if password with # is not a issue for vsphere, we just need a vsphere regression test against pr#2686 or any other pr missed here?
# ./openshift-install version ./openshift-install v4.3.0 built from commit 2055609f95b19322ee6cfdd0bea73399297c4a3e release image quay.io/openshift-release-dev/ocp-release@sha256:3a516480dfd68e0f87f702b4d7bdd6f6a0acfdac5cd2e9767b838ceede34d70d I used v4.3.0 installer without pr merged for above test.
(In reply to liujia from comment #3) > we just need a vsphere regression test against pr#2686 or any other pr missed here? Thank you for your accurate report! TL;DR: I can confirm you're not missing anything. Long story: While fixing some faulty code in OpenStack, I found the same faulty code in the vSphere logic. So I thought I'd fix it the same way as I did for OpenStack, even though I have never run vSphere. That specific code is apparently not used (yet?), Patrick Dillon refers to that fact in the PR. Just like you, I believe that once regression testing is happy, this can be safely closed. Thanks!
Thx for the confirm @Pierre Prinetti, will do regression test after a blocked issue #1798945 fixed.
Regression test on upi/vsphere with 4.4.0-0.nightly-2020-03-03-002753 succeed. Verified this bug.
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-2020:0581