OEM: IONOS Cloud Images

[tuunit]

Provide IONOS Cloud OEM images

Implements: https://github.com/flatcar/Flatcar/issues/1570

This PR adds build instructions for IONOS Cloud images.

We currently use temporary commit hashs for cloud-init and ignition support from flatcar/coreos-cloudinit#29, flatcar/init#127 and coreos/ignition#1957

How to use

Download or build the image: http://bincache.flatcar-linux.net/images/amd64/9999.0.1+feat-ionoscloud-support/flatcar_production_ionoscloud_image.qcow2

Just build the image:

./run_sdk_container -t -a amd64 -n sdk_container
./build_packages
./build_image
./image_to_vm.sh --from=../build/images/amd64-usr/latest --board=amd64-usr --format ionoscloud

Decompress and upload to your IONOS Cloud account:

https://docs.ionos.com/cloud/storage-and-backup/block-storage/images-snapshots/private-images

# Decompress
bzip2 -d flatcar_production_ionoscloud.qcow2.bz2

# Upload
ionosctl img upload -l <location> \ 
  --cloud-init V1 --licence-type LINUX \
  --disc-virtio-hot-plug true \
  --disc-scsi-hot-plug true \
  --disc-virtio-hot-unplug true \
  --disc-scsi-hot-unplug true \
  --image flatcar_production_ionoscloud.qcow2

Testing done

The image has been built from this PR and was used to create IONOS Cloud Compute Engines (VMs) using it.

We have tested the following:

• [x] Correct Hostname (through DHCP)
• [x] Successful ignition run using custom patched version from mentioned PR (changed hostname through /etc/hostname)
• [x] Successful cloud-init run using custom patch version from mentioned PR

Open Issues

• [X] Cannot verify cloud-init build because the EGIT_COMMIT of sdk_container/src/third_party/coreos-overlay/coreos-base/coreos-init/coreos-init-9999.ebuild is not respected. No idea why this happens but after manually forcing an emerge emerge-amd64-usr coreos-init it works.
• [x] When ignition successfully runs. The instance autologins to root instead of core user and does not initialize the network (DHCP resolve doesn't work either) until a first reboot occurs
• [x] Authorized SSH key files created through ignition in ~/.ssh/authorized_keys.d/ aren't respected. This is due to the same issue as above. that the system doesn't properly boots after ignition has been run and therefore the service update-ssh-keys-after-ignition is not being triggered. After a restart the system starts properly but the conditions of the service aren't met anymore because the boot id obviously changed.

Requirements

• [ ] Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• [ ] Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[tormath1]

@tuunit many thanks for your contribution! Before reviewing, would you mind opening a new issue here: https://github.com/flatcar/Flatcar/issues/new?assignees=&labels=kind%2Ffeature&projects=&template=enhancement-or-feature-request.md&title=%5BRFE%5D ?

For new platform we usually create a dedicated issue to track various steps (this one, the documentation, testing, etc.)

EDIT: Similar to https://github.com/flatcar/Flatcar/issues/1412 for example

[github-actions[bot]]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/11454753020

[tuunit]

Hi @tormath1 I was going to do that in an hour or so anyways. Wasn't expecting anyone to look at these PRs so fast 😅 I intentionally kept them as Draft PRs to signal that they are not ready for review. Obviously I will provide more details and proper descriptions. Thanks anyways for already having a look at it.

[mcbenjemaa]

I tested the build, and it works ✅