Bug 1149701 - Ignition needs to autodetect the platform
Ignition needs to autodetect the platform
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kubic
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Ignaz Forster
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2019-09-06 07:34 UTC by Fabian Vogt
Modified: 2021-07-27 11:34 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2019-09-06 07:34:26 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
Comment 1 Ignaz Forster 2019-09-06 09:39:39 UTC
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.
Comment 2 Ignaz Forster 2019-09-23 11:29:48 UTC
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.
Comment 3 Ludwig Nussel 2020-06-03 12:39:13 UTC
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?
Comment 4 Ludwig Nussel 2020-06-03 12:39:27 UTC
ignition-dracut %post that is
Comment 5 Ignaz Forster 2020-06-29 08:48:04 UTC
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.
Comment 6 Ignaz Forster 2020-06-29 23:08:02 UTC
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.
Comment 7 Anthony Rabbito 2021-07-22 13:16:20 UTC
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
Comment 8 Anthony Rabbito 2021-07-22 13:17:23 UTC
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
Comment 9 Ignaz Forster 2021-07-27 06:44:15 UTC
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).
Comment 10 Anthony Rabbito 2021-07-27 11:34:25 UTC
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.