Bugzilla – Bug 1149701
Ignition needs to autodetect the platform
Last modified: 2021-07-27 11:34:25 UTC
Currently the platform ignition runs on has to be specified manually on the kernel cmdline with ignition.platform.id and not specifying it at all breaks booting completely.
What needs to happen instead is that if ignition.platform.id is not specified by ignition is supposed to run, it makes some educated guesses which platform it is running on (vmware, qemu, openstack, gce, etc.) and uses metal as fallback.
ds-identify from cloud-init can serve as inspiration: https://github.com/cloud-init/cloud-init/blob/master/tools/ds-identify
For clarification: Currently there is no user interaction required (i.e. not "manually" in the sense of "the user has to change it"). An educated guess of the platform will be performed by the package's post script on regular installations and by setting the kernel parameters in KIWI.
As long as KIWI will continue building a separate image for each platform this is working reasonably fine, but implementing this in Ignition itself would definitely be the better way from our perspective. This will need to be discussed with the upstream project.
I've been discussing this with a CoreOS developer at All Systems Go!. The general feedback was that there isn't any interest in it, as it doesn't match the intended design (with them having to provide a separate image with provider specific stuff for each platform anyway) and because of the fear of potential security implications (e.g. by querying random IP addresses).
I guess it's still worth to open a ticket upstream to have these things documented and / or gather additional feedback.
AFIACS the ignition %post script just runs "virt-what" to set platform.id. Shouldn't that also work dynamically in initrd if virt-what was included there?
ignition-dracut %post that is
Executing `virt-what` during initrd should be possible: As long as the platform is set as soon as Ignition is called everything should be fine.
For detection of our target platforms `virt-what`, `virt-what-cpuid-helper` and `dmidecode` will have to be installed to the initrd.
The huge advantage of implementing this in the initrd directly is that we can get rid of the very hacky %post / %postun scripts `sed` to /etc/default/grub to inject the platform there.
Moved detection of virtualization environments into initrd: https://build.opensuse.org/request/show/817785
Our cloud images are not using Ignition anyway, so that detection should be enough for now.
Is it possible to have this re-opened? I have a use-case for running Kubic in a few different cloud-environments and we need to have environments ignition.platform.id set. Ref - https://build.opensuse.org/request/show/907618?notification_id=27066471#comments-list
AFAIK there's no way within ignition to detect the platform it's running on. FCOS builds multiple provider images. https://getfedora.org/en/coreos/download?tab=cloud_launchable&stream=stable
That's correct, Ignition itself does not provide any autodetection mechanism.
The Cloud team is providing platform specific Cloud images for several of our SLE products including Ignition support. So wouldn't it make sense to also do so for our openSUSE distributions?
If it really isn't an option to build Cloud provider specific images, then we may indeed think about splitting out the *ds-identify* binary from the cloud-init package and use it to detect the platform. From a quick look the only notable dependency seems to be *dmidecode*, which is present in the initrd already anyway for systemd-detect-virt, which is the current detection application (which detects VM and container technologies, but no cloud providers).
Indeed I think it would be nice if the cloud team packaged and published Kubic as an official AMI. I've been in touch with cabelo who publishes a few OpenSUSE AWS AMI's and he said he'd take a look and getting kubic published.
In the meantime and for what it's worth AWS image needs a little more then just changing the ignition.platform.id (https://build.opensuse.org/package/show/home:anthr76:kutara/kubic-images)
I have yet to physically test these images yet but should get around to it this week.