OEM: IONOS Cloud Images

[tuunit]

Provide IONOS Cloud OEM images

Implements: flatcar/Flatcar#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:

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

Open Issues

• 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.
• 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
• 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 flatcar/Flatcar#1412 for example

[github-actions]

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 don’t think this is a good idea to enable autologin

[tormath1]

It depends on the cloud provider actually - if on Ionos you have access to the instance console you can still reboot the instance and inject the flatcar.autologin from the Grub menu. See here for more details: #1866 (comment)

[tuunit]

This is not intended to be kept. Just helps me with debugging things while I finish the setup. Sorry I shouldn't have opened the PRs yet.

[mcbenjemaa]

I tested the build, and it works ✅

[jepio]

@tuunit can you put a date on when a metadata server will be introduced by IONOS Cloud? I wouldn't want this workaround to stay around forever, as it is likely to interfere with evolutions to the rootfs.

[tuunit]

Unfortunately not, I can ask again internally but it will most definitely stay like this for a long time. Up to a year or longer.