Thanks for opening a bug report! Before hitting the button, please fill in as much of the template below as you can. If you leave out information, it's harder to help you. Be ready for follow-up questions, and please respond in a timely manner. If we can't reproduce a bug we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. Version: $ openshift-install version stall 4.10.0-0.nightly-2021-10-16-173656 built from commit 95361b7f82a6539d78c170c6677de3fac776bb8d release image registry.ci.openshift.org/ocp/release@sha256:ad3e0e971d2df07c7013925f59a9113603f7fea1eef2fc18dec2d7e740bbeb1f release architecture amd64 Platform: openstack Please specify: IPI What happened? OS_CLOUD set when executing `openshift-install create cluster` will overwrite whatever I have as `platform.openstack.cloud` in install-config.yaml. This may result in creating resources in a wrong project or even cloud. This is not true when `openshift-install destroy cluster` is executed, leading to a situation when trying to destroy such broken cloud will just delete all metadata and user will be required to clean the wrong project manually. Also as create uses Terraform and destroy not, it seems to point to a Terraform configuration problem as a root cause. What did you expect to happen? `platform.openstack.cloud` takes precedence over OS_CLOUD. How to reproduce it (as minimally and precisely as possible)? Set cloud foo in install-config.yaml, export OS_CLOUD=bar, run `openshift-install create cluster` and see that Terraform will create resources in cloud bar.
Related: Bug 1876815 Bug 1813949
My understanding of the story: INITIAL STATE: the configuration for the whole Installer (Go code + Terraform) is overridden by OS_* environment variables. --> Bug 1876815 is fixed by unsetting OS_CLOUD each time a client is generated STATE 1: both Gophercloud and Terraform ignore the OS_CLOUD env var, but other OS_* environment variables are obeyed --> Bug 1813949 is fixed by setting an env var prefix in Gophercloud. All OS_* variables are now ignored when generating a Gophercloud service client in the Installer. This patch reverts the previous patch: unsetenv(OS_CLOUD) is removed. STATE 2: All OS_* environment variables are ignored when generating a Gophercloud service client from within the Installer. Terraform is behaviour is brought back to that of the Initial state. --- Open question: why is Terraform letting an OS_CLOUD environment variable taking precedence over the value that the Installer passes? I believe this is a low/medium. We will prioritise accordingly.
For the record, these environment variables did not pose problem in my tests: OS_USERNAME OS_PASSWORD OS_PROJECT_NAME OS_AUTH_URL OS_TENANT_ID OS_REGION_NAME The proposed fix is then only focusing on OS_CLOUD.
Removing the Triaged keyword because: * the QE automation assessment (flag qe_test_coverage) is missing
Verified using the following steps: 1. Unset OS_CLOUD and OS_CLOUDNAME 2. Set OS_CLOUD to foo (Which doesn't exist) 3. Set platform.openstack.cloud to 'shiftstack' in install-config.yaml Version: OCP 4.10.0-0.nightly-2021-11-27-004934 RHOS-16.1-RHEL-8-20210903.n.0
set qe_test_coverage to "-" because testing the Installer's Terraform response to install-config properties is very expensive and I don't think that this particular bug is worth it.
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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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/RHSA-2022:0056