To add support use pre-built peer-pod VM images

[savitrilh]

Enable the use of pre-built virtual machine (VM) images for peer-pods

Currently, admin users can create the virtual machine (VM) image for a peer-pod through OSC. Each pod end user is required to launch their pods within a peer-pod virtual machine (VM) based on this OSC built peer-pod image. Admin users cannot use pre-built peer-pod VM images without manually updating the image id in config map and loading/storing the pre-built image in the specified storage.

With this proposal, it provides a facility for admin users to use the pre-built peer-pod VM image. Admin users can choose to pull the required pre-built virtual machine (VM) image from the container registry(wrap a pre-built virtual machine(VM) QCOW2 image as a container image and place it in a container registry). Each pod end user is required to launch their pods within a peer-pod virtual machine (VM) based on this pre-built image. Content of the OCI artifact can have gzipped raw or qcow2 image and also have metadata about the image (checksum of image, supported architectures, OS type).

Proposal

Admin users can choose either a pre-built peer-pod VM image or operator-built peer-pod VM image. Based on the provider specific image config data, the following operations will be performed: Images will be unwrapped and suitable steps will be performed to create the provider specific image. Uploaded the image to provider specific storage locations(For example: Uploaded to libvirt Volume or azure vm image or aws ami etc).

Currently, this support will be enabled for the Libvirt provider and image type will be QCOW2. In future, this functionality can be enhanced for to all providers and also for all OCI artifacts such as gzipped raw or qcow2.

In this approach, admin users can specify this option(LIBVIRT_IMAGE_TYPE) in the config file libvirt-podvm-image-cm.yaml file. All peer-pods virtual machines (VM) are based on the same image. Suppose admin user specify the LIBVIRT_IMAGE_TYPE as operator-built or this option is not provided, the operator bulits the peer-pod image.

Note: Modifications are marked in red

Config Changes for pre-built

For Pre-built Image: Note:wrap a pre-built virtual machine(VM) QCOW2 image as a container image and place it in a container registry

Based on libvirt-podvm-image-cm file details, pulling image as follows:

Note: Created following new config files for libvirt sandboxed-containers-operatorconfig/peerpods/podvm/libvirt-podvm-image-cm.yaml sandboxed-containers-operator/config/peerpods/podvm/osc-podvm-upload-job.yaml

1. OSC Operator image generator creates the new job osc-podvm-upload-job.yaml to perform the following operations: => Validates the specified registry access => Pull the specified wrapped QCOW image => Extract pre-built peer-pod VM image
2. Operator store the extracted peer-pod VM and place on the specified volume
3. All peer-pods uses this image

[bpradipt]

It would be good to have a generic design for pulling podvm image via an OCI artifact (container image). Few things to keep in mind

1. Content of the OCI artifact - gzipped raw or qcow2 image, checksum, any other metadata like supported providers, arch etc?
2. Then based on the configured provider, suitable steps will be performed to create the provider specific image - like libvirt volume, azure vm image or aws ami etc
3. Should the operations be performed by a separate job or the existing job with different options will suffice
4. To start with the first implementation can be for libvirt provider and noop for other providers. But design should be generic.

[savitrilh]

3. Should the operations be performed by a separate job or the existing job with different options will suffice

Operations will be performed by a separate job as this requires very few operations.

[savitrilh]

https://docs.google.com/document/d/1HMbmrwRtLbxOUJ7z7KW86XcmRWllZZBW8sn-1m-pgqE/edit

[savitrilh]

@bpradipt Incorporated the review comments. I tried making it general and details about the design is specific to libevirt provider