Add support for IONOS Cloud

[mcbenjemaa]

This PR will add support for the IONOS Cloud provider. IONOS Cloud doesn't officially have a metadata service, as it's currently in development. However, the IONOS Cloud injects user-data into /var/lib/cloud/seed/nocloud/user-data directly into the volume.

I just want help in how I can test this.

[prestist]

Okay so to help with the adding of this platform I highly recommend submitting a platform request issue to =>

https://github.com/coreos/fedora-coreos-tracker/issues/new/choose

It will ask questions and give us a tracker so that we can monitor the adding support bit.

then lets squash and update the first commit to be providers: add support for ionos cloud (or what you feel fits it best)

with a reference to the aforementioned tracker.

[travier]

However, the IONOS Cloud injects user-data into /var/lib/cloud/seed/nocloud/user-data directly into the volume.

This is really unusual. How is this supposed to work? This would mean that Ignition would have to mount to root/var partition first to read the config and then act on it? This feels really brittle.

Okay so to help with the adding of this platform I highly recommend submitting a platform request issue to => coreos/fedora-coreos-tracker/issues/new/choose

It will ask questions and give us a tracker so that we can monitor the adding support bit.

Second this comment here. We need a clearer picture of how things work here.

[mcbenjemaa]

@travier

This is really unusual. How is this supposed to work? This would mean that Ignition would have to mount to root/var partition first to read the config and then act on it? This feels really brittle.

I'm afraid that's the only way, it work for now. the file /var/lib/cloud/seed/nocloud/user-data is injected into the Image.

However, we are adding information and defining how things work as much as we can,

thanks

[tuunit]

However, the IONOS Cloud injects user-data into /var/lib/cloud/seed/nocloud/user-data directly into the volume.

This is really unusual. How is this supposed to work? This would mean that Ignition would have to mount to root/var partition first to read the config and then act on it? This feels really brittle.

Okay so to help with the adding of this platform I highly recommend submitting a platform request issue to => coreos/fedora-coreos-tracker/issues/new/choose It will ask questions and give us a tracker so that we can monitor the adding support bit.

Second this comment here. We need a clearer picture of how things work here.

Yes, indeed it is brittle and we would love to have a proper metadata server in the future. Unfortunately, this will not be implemented anytime soon and we would really love to already get support for ignition especially in Flatcar Linux.

[tuunit]

Hi @prestist, @travier, @jlebon,

please have another look at the latest state of the PR. We successfully ran this version on our test VMs.

[jlebon]

Overall, I'm very wary of getting this in. I don't think the platform should touch the rootfs, nor that Ignition should try to mount it. I would prefer to wait until there is a metadata server available.

If we really must rely on this "config injector" temporarily, then I would extend the hack on that side so that it knows if it's e.g. FCOS or Flatcar Linux and have it inject in a different place (e.g. for FCOS, as described in https://github.com/coreos/ignition/pull/1957#discussion_r1813194825).

[tuunit]

Overall, I'm very wary of getting this in. I don't think the platform should touch the rootfs, nor that Ignition should try to mount it. I would prefer to wait until there is a metadata server available.

If we really must rely on this "config injector" temporarily, then I would extend the hack on that side so that it knows if it's e.g. FCOS or Flatcar Linux and have it inject in a different place (e.g. for FCOS, as described in https://github.com/coreos/ignition/pull/1957#discussion_r1813194825).

Thanks for your review!

One remark and maybe I just misunderstand how ignition works internally but doesn't ignition mount the rootfs anyways at /sysroot every time it has to write files and change system configurations? So why would it be a problem to temporarily mount it for a quick lookup of the user-data file?

Just for context regarding the config injector: It has been like that since the inception of the company a decade or so ago and is older than ignition itself. It is managed by another department responsible for the virtual machine management and unfortunately we cannot influence how quickly they will churn out the metadata server. The current estimation is it will take a couple of months and possibly up to a year.

[jlebon]

One remark and maybe I just misunderstand how ignition works internally but doesn't ignition mount the rootfs anyways at /sysroot every time it has to write files and change system configurations?

The rootfs is mounted by the OS, and the files stage is run after that.

This also all happens quite late in the initrd process, not long before switching root. On the other hand, the fetch-offline stage happens quite early in the boot process.

[tuunit]

So for me to fully understand the phases and issue:

Stage order: fetch-offline [-> fetch] [-> kargs] -> disks -> mount -> files.

                                       dracut(initramfs)              ignition targets
-----------------------------------------------------------------------------------------------------------
                                         basic.target
                                               |
                        ______________________/|
                       /                       |                 ignition-fetch(-offline).target
                       |                       v
                       |            initrd-root-device.target
                       |                       |
                       |                       v
                       |            dracut-pre-mount.service
                       |                       |
                       |                       v
                       |                  sysroot.mount
                       |                       |                ignition-remount-sysroot.service
                       |                       v
                       |             initrd-root-fs.target
           (custom initrd services)            |
                       |                       |                ignition-mount.target
                       |                       v                ignition-files.target
                       |             dracut-mount.service
                       |                       |
                       |                       v
                       |            initrd-parse-etc.service
                       |                       |
                       |                       v
                       |            (sysroot-usr.mount and
                       |             various mounts marked
                       |               with fstab option
                       |                x-initrd.mount)
                       |                       |
                       |                       v
                       |                initrd-fs.target
                       \______________________ |
                                              \|
                                               v
                                          initrd.target
                                               |
                                               v
                                    dracut-pre-pivot.service
                                               |
                                               v
                                     initrd-cleanup.service
                                          isolates to
                                    initrd-switch-root.target

So your concern is the fetching stage of ignition could be run before the sysroot mount is done and therefore potentially fail if the disk is yet ready?

[tuunit]

From my point of view: This means we will have to keep the patch files for ignition inside Flatcar for now and postpone the official addition to CoreOS and Ignition until IONOS has released a working metadata server.

CC: @mcbenjemaa @tormath1