-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for IONOS Cloud #1957
base: main
Are you sure you want to change the base?
Conversation
) | ||
|
||
const ( | ||
defaultFilename = "/var/lib/cloud/seed/nocloud/user-data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, do you have documentation for this, I am not having any luck finding the default user-data file location for IONOS
I thought cloud-init's default was something like "/var/lib/cloud/instance/user-data"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally It might be good to add a reference to the in development metatdata service for this, so we can replace it when completed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, we don't have that documented publicly.
Its just a internal docs.
However this docs explains how can use Userdata.
https://docs.ionos.com/cloud/compute-services/compute-engine/how-tos/boot-cloud-init
The path is /var/lib/cloud/seed
So it could be detected by the NoCloud Datasource.
So, im 100% sure of that.
But the /var/lib/cloud/instance is the information about the cloud-init run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prestist I can back this up as well. We don't have this publicly documented. Unfortunately, as of yet we don't have a metadata server at IONOS and therefore rely on a legacy script that injects data into this file before a VM is booted for the first time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay, yeah that makes sense. Ok, would it be okay to just add a comment to point to documentation?
Thank you both for answering my questions.
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 with a reference to the aforementioned tracker. |
6cbf57a
to
48c1e5e
Compare
48c1e5e
to
c2cdecd
Compare
c2cdecd
to
c269f14
Compare
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.
Second this comment here. We need a clearer picture of how things work here. |
I'm afraid that's the only way, it work for now. However, we are adding information and defining how things work as much as we can, thanks |
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. |
) | ||
|
||
const ( | ||
defaultFilename = "/var/lib/cloud/seed/nocloud/user-data" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work. Ignition runs from the initramfs and the /var
there is different. You could inject it in what would become /var
in the real root, but you'd have to special-case code for CoreOS which feels really like a layering violation.
At least for FCOS, probably the simplest way to hack around this for now (until there's a proper metadata service) is to inject the Ignition config in the boot partition (GPT partition label boot
) at /ignition/config.ign
. I'm not sure if there's an equivalent on the Flatcar side. We wouldn't even need to touch Ignition for that; the QEMU qcow2 image we publish should work for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, we just had a chat and realized this fact as well. In case of Flatcar the root partition is mounted to /sysroot
and therefore the path is wrong anyway. I'll try to build a flatcar image using a patch version of ignition and we need to investigate how to make it work on other distributions and make the base path configurable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tormath1 am I right on this on? Regarding the /sysroot
being a mount point of the boot partition?
return types.Config{}, report.Report{}, err | ||
} | ||
|
||
if util.IsCloudConfig(rawConfig) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should we tolerate non-Ignition configs here? The reason this is done in Proxmox VE is because the platform itself uses cloud-init to pass through platform values which is extremely unfortunate because it makes it harder for users to provide their own config and deteriorates the UX. Is that the case for this platform as well? How can we avoid it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed this is ugly DX not going to deny that fact. But we cannot change that as of now because the IONOS Cloud fully builts on the premise that all images use cloud-init. Which is why our legacy pre-boot image injector scripts write this specific cloud-init seed file. Meanwhile our team wants to introduce ignition to support linux derivatives that use it instead of cloud-init. Therefore we need to re-purpose this seed file to get earlier support until the Compute department at IONOS introduces a proper metadata service. It is definitely on the roadmap but will take months or possibly a year. Therefore this intermediate implementation will unfortunately (as so often the case with these things) be a long living temporary solution.
9e2a8ff
to
488d302
Compare
return nil, err | ||
} | ||
|
||
if util.IsCloudConfig(contents) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can get rid of this check, I believe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no we cannot, we want to ignore the file and do nothing if the config contains the #cloud-config
directive
4d20b27
to
7b7a434
Compare
Add support for IONOS Cloud Add check to ignore cloud-config Add mounting of root partition Add better documentation Co-authored-by: Jan Larwig <[email protected]>
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 #1957 (comment)). |
Thanks for your review! One remark and maybe I just misunderstand how ignition works internally but doesn't ignition mount the rootfs anyways at 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. |
The rootfs is mounted by the OS, and the 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. |
So for me to fully understand the phases and issue: Stage order: fetch-offline [-> fetch] [-> kargs] -> disks -> mount -> files.
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? |
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 |
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.