Add support for IONOS Cloud #1957

mcbenjemaa · 2024-10-17T13:48:07Z

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 · 2024-10-18T19:05:46Z

internal/providers/ionoscloud/ionoscloud.go

+)
+
+const (
+	defaultFilename = "/var/lib/cloud/seed/nocloud/user-data"


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"

Additionally It might be good to add a reference to the in development metatdata service for this, so we can replace it when completed.

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.

@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.

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.

prestist · 2024-10-21T19:00:39Z

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.

internal/providers/ionoscloud/ionoscloud.go

travier · 2024-10-22T14:50:42Z

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 · 2024-10-22T15:01:05Z

@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 · 2024-10-23T09:37:32Z

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.

jlebon · 2024-10-23T17:01:38Z

internal/providers/ionoscloud/ionoscloud.go

+)
+
+const (
+	defaultFilename = "/var/lib/cloud/seed/nocloud/user-data"


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.

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

@tormath1 am I right on this on? Regarding the /sysroot being a mount point of the boot partition?

jlebon · 2024-10-23T17:14:31Z

internal/providers/ionoscloud/ionoscloud.go

+		return types.Config{}, report.Report{}, err
+	}
+
+	if util.IsCloudConfig(rawConfig) {


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?

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.

tuunit · 2024-11-04T12:11:34Z

Hi @prestist, @travier, @jlebon,

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

mcbenjemaa · 2024-11-04T13:27:23Z

internal/providers/ionoscloud/ionoscloud.go

+		return nil, err
+	}
+
+	if util.IsCloudConfig(contents) {


we can get rid of this check, I believe.

no we cannot, we want to ignore the file and do nothing if the config contains the #cloud-config directive

jlebon · 2024-11-07T16:56:14Z

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)).

tuunit · 2024-11-07T17:34:40Z

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 /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 · 2024-11-07T17:49:05Z

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 · 2024-11-08T08:24:40Z

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 · 2024-11-08T11:34:30Z

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

tuunit · 2025-01-17T09:36:10Z

Hi @prestist, @jlebon, @travier,

I've completely changed the implementation. We made some changes on our end and can now support user data injection on any partition or additional disk / drive.

Please have a look at the updated code :) If you think this looks like an approach we can continue with, let me know and I'll update the documentation and finalise the PR with the help of your feedback.

Best,
Jan

CC: @mcbenjemaa @tormath1

prestist · 2025-01-20T19:21:12Z

Awesome and thank you!
I will set some time aside to look through it, I will also reach out to @jlebon and @travier.

tuunit · 2025-01-20T19:29:47Z

Awesome and thank you! I will set some time aside to look through it, I will also reach out to @jlebon and @travier.

Fixed the linting issue.

prestist

Thank you for these changes, from my perspective this lgtm, I want to wait on the input from other members before merging. As they likely have more insight then me. @jlebon @travier when you have the chance could you take a look please given the situation this seems reasonable IMO.

travier

Looks more reasonable. Some comments.

travier · 2025-02-03T19:05:42Z

internal/providers/ionoscloud/ionoscloud.go

+// The IONOS Cloud provider fetches the ignition config from the user-data
+// available in an injected file at /var/lib/cloud/seed/nocloud/user-data.
+// This file is created by the IONOS Cloud VM handler before the first boot
+// through the cloud init user data handling.


I don't think this is accurate anymore.

travier · 2025-02-03T19:13:36Z

internal/providers/ionoscloud/ionoscloud.go

+	deviceLabelKernelFlag = "ignition.config.device"
+	defaultDeviceLabel    = "OEM"
+	userDataKernelFlag    = "ignition.config.path"
+	defaultUserDataPath   = "config.ign"


So this introduces two new kernel arguments just for that provider. What are the reason that would require those to be configurable?

Overall, those kernel arguments would have to be baked into the image so I don't think this brings any advantage versus fixed values in the code directly.

Because users of our Cloud environment might build their own images that utilise ignition and can decide on which partition or device the user-data is supposed to be injected for better isolation of concerns.

For Flatcar we already need two different configurations. One used as the base image used for the kubernetes-sigs/image-builder project and one image used for general purpose VMs. Furthermore, we are working on some OpenShift related topics and want to allow for this flexibility.

I don't understand how that would work. Those values would have to be set in the image and the images are not customized for each deployment (which is the goal of Ignition) so those values will be fixed.

How would you be using this?

@travier

Those values would have to be set in the image

Yes indeed most of the time you need to build customized images for the IONOS Cloud anyway at the moment.

As long as they are QEMU compatible images, our VM handler will create a VM for a customer. Unfortunately without some changes to the image, ignition or cloud-init won't work out of the box. I'm currently trying to get hold of the team responsible for publishing our documentation to get our official Cloud docs up to date on this topic.

I tried to summarize the important points

First some clarification regarding the image requirements:

The filesystem needs to be ext4 (some others are also supported but definitely not btrfs)

For cloud-init support, the file /etc/cloud/cloud.cfg needs to exist.

Regarding the experimental support for ignition

With the current implementation we have the following options:

Add an OEM labelled drive containing a file called USER_DATA_INJECTION_RHCOS or USER_DATA_INJECTION_FLATCAR to signalize to the IONOS VM handler to inject the user data in that location. If it is an additional drive to the VM boot drive, no changes necessary for RHCOS images. This essentially acts as a rudimentary config drive.

Build a custom image with a dedicated partition, named either OEM or otherwise and create a USER_DATA_INJECTION_RHCOS file inside of it. If the partition is labelled differently, configure the kernel flags in your grub config.

For example for Flatcar CAPI we set the kernel flags in the grub config like so:

set linux_append="flatcar.autologin ignition.config.device=OEM ignition.config.path=config.ign"

I fully know that this is unusual (and ugly) and yes I told the responsible VM provisioning team that this is not up to standards. Me and my colleague just try to get RHCOS and Flatcar supported with what we have. All of this will be explained in more detail in a How-To guide in our official docs in the future:
https://docs.ionos.com/cloud/compute-services/compute-engine/how-tos

Add an OEM labelled drive containing a file called USER_DATA_INJECTION_RHCOS or USER_DATA_INJECTION_FLATCAR to signalize to the IONOS VM handler to inject the user data in that location. If it is an additional drive to the VM boot drive, no changes necessary for RHCOS images. This essentially acts as a rudimentary config drive.

Why not include the userdata/ignition config directly in this drive?

Build a custom image with a dedicated partition, named either OEM or otherwise and create a USER_DATA_INJECTION_RHCOS file inside of it. If the partition is labelled differently, configure the kernel flags in your grub config.

If I understand correctly, this means that you need to upload a different image every time you want to change your ignition config?

What is your concern about using kernel flags?

Ah ok you ment a built option for ignition itself. I don't think this would work for us and it would reduce flexibility.

Can you clarify why this would not work?

What is your concern about using kernel flags?

It introduces variability where there is no need for it. As far as I know, no other provider rely on kernel flags.

As far as I know, no other provider rely on kernel flags.

I got the idea from this: https://github.com/coreos/ignition/blob/main/internal/providers/cmdline/cmdline.go

Can you clarify why this would not work?
It introduces variability where there is no need for it.

Because we don't control the whole ecosystem:

The IONOS Cloud doesn't have a metadata server (I wish it would but it doesn't. Which is why we call this an experimental implementation). And a metadata server is how other providers enable flexibility.

We want to give others the flexibility to decide how to use it. Either change the underlying OS image or just add another "config drive" labelled OEM.

In case of CAPI support for Flatcar. Flatcar injects the ignition config for the packer build into OEM/config.ign (we don't control this part). And later when actually starting a new image from the newly created image. We require ignition to fetch the config from OEM/config/user-data

As far as I understand, what you mentioned here does not contradict what I'm suggesting above. With the build time variables, distributions can control where they want the config to be placed.

I got the idea from this: main/internal/providers/cmdline/cmdline.go

This is how you can tell Ignition to fetch a config from the kernel command line. This is mostly intended for bare metal use cases or cases where the user would be in front of the system and interactively entering the URL to the config.

travier · 2025-02-03T19:14:02Z

docs/supported-platforms.md

@@ -20,6 +20,7 @@ Ignition is currently supported for the following platforms:
 * [Hetzner Cloud] (`hetzner`) - Ignition will read its configuration from the instance userdata. Cloud SSH keys are handled separately.
 * [Microsoft Hyper-V] (`hyperv`) - Ignition will read its configuration from the `ignition.config` key in pool 0 of the Hyper-V Data Exchange Service (KVP). Values are limited to approximately 1 KiB of text, so Ignition can also read and concatenate multiple keys named `ignition.config.0`, `ignition.config.1`, and so on.
 * [IBM Cloud] (`ibmcloud`) - Ignition will read its configuration from the instance userdata. Cloud SSH keys are handled separately.
+* [IONOS Cloud] (`ionoscloud`) - Ignition will read its configuration from the instance user-data. Per default the user-data are injected on a disk or partition with the label `OEM` which can be customized using the environment variable `IGNITION_CONFIG_DEVICE_LABEL`. 


This looks outdated? See other comment.

Add support for IONOS Cloud Add check to ignore cloud-config Add mounting of root partition Add better documentation Signed-off-by: Jan Larwig <[email protected]>

…cessary if else block Signed-off-by: Jan Larwig <[email protected]>

Signed-off-by: Jan Larwig <[email protected]>

jlebon

@travier I think what @tuunit is saying here is that for Flatcar, they need to support both config.ign and config/user-data for the path component, so it can't be done at compile-time.

What is your concern about using kernel flags?

Hmm, I think having an Ignition provider be parameterized this way is a tell that we might not be going about this the right way. Provider code should already have all the information it needs to correctly interface with that provider's APIs. If you can afford to edit kargs in disk images, then you're already doing something quite advanced. It'd be better I think in that case to provide generic mechanisms that aren't tied to a specific provider.

As you mentioned, there is the cmdline provider, which today already knows to look at ignition.config.url. So one path forward is to extend that to also support ignition.config.device and ignition.config.path. Note the cmdline provider is always active regardless of the actual ignition.platform.id value.

And if we have that, do we even even need an IONOS provider for now?

In the CAPI flow where you're customizing disk images, you can inject the kargs and add the marker file wherever you'd like.
Flatcar is free to provide an "IONOS Cloud" disk image, where it can add a marker and inject the appropriate kargs, but use the metal platform ID.
I'm not keen on having a disk image for FCOS doing the same, but the community may decide to. But regardless, a user would be free to customize our QEMU image similarly too (I guess this could fall under our "emerging platforms support" which already requires users to do work before they get a usable image).

Then, when IONOS Cloud actually has a proper metadata service, we can circle back and add a backend here.

jlebon · 2025-02-06T18:13:20Z

internal/providers/ionoscloud/ionoscloud.go

+	if util.IsCloudConfig(contents) {
+		logger.Debug("disk (%q) contains a cloud-config configuration, ignoring", device)
+		return nil, nil
+	}
+
+	if util.IsShellScript(contents) {
+		logger.Debug("disk (%q) contains a shell script, ignoring", device)
+		return nil, nil
+	}


Can you elaborate on why we need this?

Backwards compatibility for the Flatcar CoreOS CloudInit fork. But to be honest we don't really need it and can get rid of it.

tuunit · 2025-02-06T19:54:25Z

Hi @jlebon thanks for having another look at this as well :)

If you can afford to edit kargs in disk images, then you're already doing something quite advanced. It'd be better I think in that case to provide generic mechanisms that aren't tied to a specific provider.

Yes and no, we should choose reasonable default values like the OEM device label. This way people can just add a "config drive" (which isn't preferable but it would work without changes to the OS image)

Note the cmdline provider is always active regardless of the actual ignition.platform.id value.

Interesting I wasn't aware of that fact 🤔

And if we have that, do we even need an IONOS provider for now?
Then, when IONOS Cloud actually has a proper metadata service, we can circle back and add a backend here.

Sounds like a plan to me. If you are open to the idea of extending the cmdline "provider" I can move my implementation over and remove all IONOS Cloud specifics for now.

In the CAPI flow where you're customizing disk images, you can inject the kargs and add the marker file wherever you'd like.

Yes that is exactly what we do at the moment.

I'm not keen on having a disk image for FCOS doing the same, but the community may decide to. But regardless, a user would be free to customize our QEMU image similarly too (I guess this could fall under our "emerging platforms support" which already requires users to do work before they get a usable image).

Fine for us as well, we are mainly interested in RHCOS & Flatcar for now but obviously would love to be able to support all distros that use Ignition.

tuunit · 2025-02-07T08:53:49Z

Hi @travier, Hi @jlebon,

what is your first impression about:
https://github.com/coreos/ignition/compare/main...tuunit:ignition:feat/extend-cmdline-options?expand=1

Should I open a PR using that solution instead and we drop this PR in favour of extending the cmdline "provider"?

jlebon · 2025-02-07T14:09:13Z

Hi @travier, Hi @jlebon,

what is your first impression about: main...tuunit:ignition:feat?expand=1 (compare)

I have some comments I'll leave for review, but yes it looks sane overall.

Should I open a PR using that solution instead and we drop this PR in favour of extending the cmdline "provider"?

Strong 👍 from me. Curious what @travier thinks.

tuunit · 2025-02-11T12:44:17Z

Hi @tormath1, @travier, @jlebon,

sorry that I missed the meeting. I unfortunately, didn't get any notification from the poll or elements.io.

Would Thursday at 15 o'clock CET work for everyone?

tuunit · 2025-02-17T10:33:54Z

@mcbenjemaa please close the PR :)

Will be replaced by #2018

mcbenjemaa · 2025-02-17T10:40:39Z

PR closed in favor of #2018

prestist reviewed Oct 18, 2024

View reviewed changes

mcbenjemaa mentioned this pull request Oct 21, 2024

Platform Request: IONOSCloud coreos/fedora-coreos-tracker#1815

Open

mcbenjemaa force-pushed the ionoscloud branch from 6cbf57a to 48c1e5e Compare October 21, 2024 19:31

tuunit mentioned this pull request Oct 22, 2024

OEM: IONOS Cloud Images flatcar/bootengine#100

Closed

2 tasks

tormath1 reviewed Oct 22, 2024

View reviewed changes

internal/providers/ionoscloud/ionoscloud.go Outdated Show resolved Hide resolved

mcbenjemaa force-pushed the ionoscloud branch from 48c1e5e to c2cdecd Compare October 22, 2024 10:02

tormath1 reviewed Oct 22, 2024

View reviewed changes

internal/providers/ionoscloud/ionoscloud.go Outdated Show resolved Hide resolved

mcbenjemaa force-pushed the ionoscloud branch from c2cdecd to c269f14 Compare October 22, 2024 13:54

tuunit mentioned this pull request Oct 23, 2024

[RFE] IONOS Cloud support flatcar/Flatcar#1570

Open

5 tasks

jlebon reviewed Oct 23, 2024

View reviewed changes

tuunit force-pushed the ionoscloud branch 2 times, most recently from 9e2a8ff to 488d302 Compare November 1, 2024 08:42

tuunit mentioned this pull request Nov 4, 2024

OEM: IONOS Cloud Images flatcar/scripts#2389

Open

8 tasks

tuunit force-pushed the ionoscloud branch from 5f56253 to 8ecbef0 Compare November 4, 2024 12:13

mcbenjemaa commented Nov 4, 2024

View reviewed changes

tuunit force-pushed the ionoscloud branch 4 times, most recently from 7b7a434 to 3d4bb8d Compare November 5, 2024 16:07

tuunit force-pushed the ionoscloud branch from 3d4bb8d to 2d637da Compare January 7, 2025 07:09

tuunit force-pushed the ionoscloud branch from 2d637da to 3a570fc Compare January 7, 2025 08:22

tuunit force-pushed the ionoscloud branch 2 times, most recently from 859b937 to 0d7109c Compare January 16, 2025 13:29

tuunit force-pushed the ionoscloud branch from 0d7109c to 12f1e8d Compare January 17, 2025 16:20

mcbenjemaa mentioned this pull request Jan 21, 2025

Support for Fatcar ionos-cloud/cluster-api-provider-ionoscloud#268

Open

5 tasks

tuunit force-pushed the ionoscloud branch 2 times, most recently from 903c5dc to 531a6dc Compare February 3, 2025 14:43

prestist approved these changes Feb 3, 2025

View reviewed changes

travier requested changes Feb 3, 2025

View reviewed changes

tuunit and others added 3 commits February 4, 2025 10:53

providers: add support for ionos cloud

a3881ec

Add support for IONOS Cloud Add check to ignore cloud-config Add mounting of root partition Add better documentation Signed-off-by: Jan Larwig <[email protected]>

fix: linting issue directly return value of HasPrefix instead of unne…

0f6065b

…cessary if else block Signed-off-by: Jan Larwig <[email protected]>

doc: update for ionoscloud provider

bdb6ddf

Signed-off-by: Jan Larwig <[email protected]>

tuunit force-pushed the ionoscloud branch from 3f5401e to bdb6ddf Compare February 4, 2025 09:54

jlebon reviewed Feb 6, 2025

View reviewed changes

mcbenjemaa closed this Feb 17, 2025

Add support for IONOS Cloud #1957

Add support for IONOS Cloud #1957

Conversation

mcbenjemaa commented Oct 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prestist commented Oct 21, 2024 • edited Loading

travier commented Oct 22, 2024

mcbenjemaa commented Oct 22, 2024

tuunit commented Oct 23, 2024

Choose a reason for hiding this comment

tuunit Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tuunit commented Nov 4, 2024

Choose a reason for hiding this comment

tuunit Nov 4, 2024 • edited Loading

Choose a reason for hiding this comment

jlebon commented Nov 7, 2024

tuunit commented Nov 7, 2024 • edited Loading

jlebon commented Nov 7, 2024

tuunit commented Nov 8, 2024 • edited Loading

tuunit commented Nov 8, 2024 • edited Loading

tuunit commented Jan 17, 2025 • edited Loading

prestist commented Jan 20, 2025

tuunit commented Jan 20, 2025

prestist left a comment

Choose a reason for hiding this comment

travier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tuunit Feb 4, 2025 • edited Loading

Choose a reason for hiding this comment

I tried to summarize the important points

Regarding the experimental support for ignition

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tuunit Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

tuunit Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jlebon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tuunit commented Feb 6, 2025

tuunit commented Feb 7, 2025 • edited Loading

jlebon commented Feb 7, 2025

tuunit commented Feb 11, 2025

tuunit commented Feb 17, 2025

mcbenjemaa commented Feb 17, 2025

prestist commented Oct 21, 2024 •

edited

Loading

tuunit Oct 24, 2024 •

edited

Loading

tuunit Nov 4, 2024 •

edited

Loading

tuunit commented Nov 7, 2024 •

edited

Loading

tuunit commented Nov 8, 2024 •

edited

Loading

tuunit commented Nov 8, 2024 •

edited

Loading

tuunit commented Jan 17, 2025 •

edited

Loading

tuunit Feb 4, 2025 •

edited

Loading

tuunit Feb 6, 2025 •

edited

Loading

tuunit Feb 6, 2025 •

edited

Loading

tuunit commented Feb 7, 2025 •

edited

Loading