Add IPI Support for IBM Power Virtual Servers Offering

[clnperez]

For more background on IPI on Power VS, refer to the enhancement
proposal here: openshift/enhancements#736

We have upstream support for Power VS in the API
(openshift/enhancements#736) and cluster api
provider (https://github.com/openshift/cluster-api-provider-powervs).
Other required work is actively ongoing in the community.

Also actively worked is support for creating networking and boot images
in a way that work with the OCP installer, so our present implemenation
requires that these items be pre-created and passed in via the
install-config. This is temporary and we will add support for IPI-creation
of all required components.

Since Power VS is an offering as part of IBM Cloud (but with seperate APIs for
provisioning), we are able to re-use some of the ibmcloud provider
funtionality. More info in the enhancement proposal on the need to have
a completley seperate provider.

Signed-off-by: Christy Norman christy@linux.vnet.ibm.com
Co-authored-by: Pradipta Banerjee bpradipta@in.ibm.com
Co-authored-by: Manjunath Kumatagi mkumatag@in.ibm.com
Co-authored-by: Mike Turek mjturek@us.ibm.com
Co-authored-by: wolf cory.klokman@ibm.com
Co-authored-by: Karthik K.N. karthik.k.n@ibm.com

[Prashanth684]

isn't the architecture specified explicitly in the control plane and compute through install config? PowerVS only makes sense for ppc64le so there should be a validation failure if the user chooses some arch other than ppc64le. but this should not be hardcoded based on platform name because we already have an arch field.

[clnperez]

yes, it is there. i didn't create a new arch field. this updates the one in the control plane section of the install-config. it doesn't seem to be an option in the survey questions. are you saying we just need to add it as a question then?

[Prashanth684]

yes that's true. but the idea was that the defaultarch would be detected based on payload: 729882a. so if you use an openshift-install binary corresponding to P and create an install config with that, the arch would be set to ppc64le for you irrespective of the platform you are installing on (because the payload was built on a P host). in that sense the "default" when building your own installer will be based on the host system on which you build the installer. the setting of this arch based on platform conflicts with that idea.

[clnperez]

so, there's going to be a specific installer binary that is an amd/x86 binary, but "corresponding to P"? (b/c clearly i'm not running a binary on my laptop to do an install that was built on a power box)

or -- there needs to be doc stating that if you're installing from a different arch than you're installing onto, you need to manually edit your install-config?

[Prashanth684]

exactly so for AWS on ARM : https://console.redhat.com/openshift/install/aws/arm we have an option to select an openshift-install binary which is an x86 binary but which is built for an ARM payload, hence the install-config will have the arch set to arm64 when created through this binary. we would need to have the same for PowerVS too. cc @yselkowitz .

[Prashanth684]

and if you locally build the installer and use that install binary, you would have to manually edit the architecture. So, the tl;dr is - arch is based on payload. If you use an openhsift-install binary from the payload you shouldn't worry about the arch. it will be set correctly. if you build the install binary locally, you will have to change the arch manually (i.e, if you are not building on a host corresponding to the arch of the platform)

[yselkowitz]

As of 4.9 all payloads regardless of architecture have a linux/amd64 installer in addition to linux/"native". Also, when you get the installer from the payload, it will default to the payload architecture, regardless of the installer binary runtime arch. If you build the installer yourself (e.g. for development purposes), you can mimic this by running e.g. DEFAULT_ARCH=ppc64le ./hack/build.sh

[Prashanth684]

testing regions should probably go under the _test.go files

[clnperez]

ah, misleading comment there. testing in this context should have been development. that TODO needs to removed and these zones need to be triple-checked. i missed a few stray TODOs there we should clean up -- including the one about programmatic generation (since we don't have a way to query zones)

[Prashanth684]

/retest

[clnperez]

looks like now we're hitting #523

[clnperez]

/retest

[clnperez]

/retest
hoping those jq errors go away