podvm: Current doc doesn't work for building s390x image in container

[stevenhorsman]

The current documentation for building the podvm image has a section with an example of building the image with s390x, but it doesn't work correctly.

The issues is (thanks to James Tumber for the debug) with the UBUNTU_IMAGE_URL and UBUNTU_IMAGE_CHECKSUM values that need to be changed for s390x. It also seems we have a bit of confused logic around these which I think might be related to the support of centos and rhel based images:

• The Makefile has logic which sets the UBUNTU_IMAGE_URL and UBUNTU_IMAGE_CHECKSUM appropriately based on the architecture being used:

  cloud-api-adaptor/podvm/Makefile

  Line 10 in f4d87fb

  UBUNTU_IMAGE_URL := $(or $(UBUNTU_IMAGE_URL),https://cloud-images.ubuntu.com/$(UBUNTU_RELEASE)/current/$(UBUNTU_RELEASE)-server-cloudimg-$(DEB_ARCH).img)

  , but I think these are only called if the value is set but empty (@wainersm should be able to confirm this). Dockerfile.podvm however sets these values:

  cloud-api-adaptor/podvm/Dockerfile.podvm

  Lines 26 to 27 in f4d87fb

  	ARG UBUNTU_IMAGE_URL=https://cloud-images.ubuntu.com/releases/focal/release-20230107/ubuntu-20.04-server-cloudimg-amd64.img
  	ARG UBUNTU_IMAGE_CHECKSUM=3895e38566e5c2c019f5c6f825ab7570ee34dac6b9142fab0c7e5a78084c4280

  so the make logic isn't called.

This results in the s390x build running based on the amd64 ubuntu image that fails without a useful error message:

238a84c82657729f7ea8b0168ce6cc1b.iso
==> qemu.ubuntu: Copying hard drive...
==> qemu.ubuntu: Resizing hard drive...
==> qemu.ubuntu: Found port for communicator (SSH, WinRM, etc): 3019.
==> qemu.ubuntu: Looking for available port between 5900 and 6000 on 127.0.0.1
==> qemu.ubuntu: Starting VM, booting disk image
    qemu.ubuntu: The VM will be run headless, without a GUI. If you want to
    qemu.ubuntu: view the screen of the VM, connect via VNC without a password to
    qemu.ubuntu: vnc://127.0.0.1:5969
==> qemu.ubuntu: Overriding default Qemu arguments with qemuargs template option...
==> qemu.ubuntu: Waiting 5m0s for boot...
==> qemu.ubuntu: Connecting to VM via VNC (127.0.0.1:5969)
==> qemu.ubuntu: Error connecting to VNC: dial tcp 127.0.0.1:5969: connect: connection refused
==> qemu.ubuntu: Deleting output directory...
Build 'qemu.ubuntu' errored after 5 minutes 58 seconds: Error connecting to VNC: dial tcp 127.0.0.1:5969: connect: connection refused

There are a few approaches we could take to try and fix this:

1. Update Dockerfile.podvm to setting the default values of UBUNTU_IMAGE_URL and UBUNTU_IMAGE_CHECKSUM to set and empty e.g.:

ARG UBUNTU_IMAGE_URL=""
ARG UBUNTU_IMAGE_CHECKSUM=""

this would release in the default release release-20230107 that was picked being lost though, but means that both the container and local build of pod vm images would release in the same image by deferring all the logic to the Makefile

2. Update the documentation to add the build args to override the Dockerfile values to set, but empty e.g.

docker build -t podvm_ibmcloud_s390x --build-arg ARCH=s390x --build-arg UBUNTU_IMAGE_URL="" --build-arg UBUNTU_IMAGE_CHECKSUM="" --build-arg BUILDER_IMG=podvm_builder:latest --build-arg CLOUD_PROVIDER=ibmcloud -f Dockerfile.podvm .

which isn't the greatest user experience, but would allow the dockerfile default release to remain (which might not be desirable)

3. Update the documentation to add the build args to override the Dockerfile values to a specific s390x release e.g.

docker build -t podvm_ibmcloud_s390x --build-arg ARCH=s390x --build-arg UBUNTU_IMAGE_URL="https://cloud-images.ubuntu.com/releases/focal/release-20230107/ubuntu-20.04-server-cloudimg-s390x.img" --build-arg UBUNTU_IMAGE_CHECKSUM=24673aa86785573d3a92e15166ff81beff88cbb0abc01938f156eb1332e87cd3  --build-arg BUILDER_IMG=podvm_builder:latest --build-arg CLOUD_PROVIDER=ibmcloud -f Dockerfile.podvm .

and provide some documentation for users as to how to find the correct value and checksum. This seems a worse user experience still, but gives the greatest customisation for users (but we could just make that optional)

4. Longer-term we could add the os versions to a centralised versioning system in Add versioning system for dependencies #598 and look up the specified values for each architecture. This is the most complicated and something we aren't ready to do just yet, but should provide the best option of dependency customisation in a single place.

[stevenhorsman]

\cc @jtumber-ibm @wainersm

[tumberino]

I think the versioning system could be added incrementally, and might not be too difficult to add in this case?

[bpradipt]

I think the default options for the image build workflow should be based on amd64 and a base distro release which we test in CI.
Any customisation - eg for multi-arch or using a different distro should be via build-args and documented. This will keep the code simple and avoid too many conditionals.
Any automation (eg bash script etc for using the right values) for non-default workflow (multi-arch or different distro) can be external to the core artefacts - Makefile, Dockerfile, build scripts.

[stevenhorsman]

I've implemented option 2 in #810, but it's worth remembering that we might want to implement a code or versions solution to this rather than documentation, so I don't want to lose the discussion completely.