Description of problem: Installing 4.2 on OSP using booting from volumes for master has started to fail. Working with latest nightly version: 01:48:58 + ./openshift-install version 01:48:58 ./openshift-install v4.2.32 01:57:18 level=error 01:57:18 level=error msg="Error: Your query returned no results. Please change your search criteria and try again." 01:57:18 level=error 01:57:18 level=error msg=" on ../../../../tmp/openshift-install-844377072/bootstrap/main.tf line 112, in data \"openstack_images_image_v2\" \"bootstrap_image\":" 01:57:18 level=error msg=" 112: data \"openstack_images_image_v2\" \"bootstrap_image\" {" 01:57:18 level=error 01:57:18 level=error 01:57:18 level=error 01:57:18 level=error msg="Error: Your query returned no results. Please change your search criteria and try again." 01:57:18 level=error 01:57:18 level=error msg=" on ../../../../tmp/openshift-install-844377072/masters/main.tf line 1, in data \"openstack_images_image_v2\" \"masters_img\":" 01:57:18 level=error msg=" 1: data \"openstack_images_image_v2\" \"masters_img\" {" 01:57:18 level=error 01:57:18 level=error 01:57:18 level=error msg="Failed to read tfstate: open /tmp/openshift-install-844377072/terraform.tfstate: no such file or directory" 01:57:18 level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply using Terraform" Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Install 4.2 using boot from volume features on install-config.yaml file 2. 3. Actual results: Installation fails Expected results: Installation is completed creating volumes for master nodes Additional info: Installation of 4.2 works fine without booting from volume
The problem is that in 4.2, the base image is hardcoded to rhcos and BFV won't read the new image name from the OPENSHIFT_INSTALL_OS_IMAGE_OVERRIDE variable. I think it's OK since OPENSHIFT_INSTALL_OS_IMAGE_OVERRIDE is only intended for developers.
This request came from QE - they use a shared tenant where they cannot make assumption about an `rhcos` image always pointing at an 4.2 rhcos image. This will allow them to test boot from volume.
The team considers this bug as valid. Considering this bug priority and our capacity, we are deferring this bug to an upcoming sprint. If there are reasons for us to reprioritise, please let us know.
Fixed in 4.3, we don't plan on backporting.