Happy to just copy everything over, similar to how the terraform scripts from flatcar/flatcar-terraform are embedded in the docs right now.

Once its available in alpha I can get the packer config down to 75-80 lines.

In reply to @tormath1:matrix.org
Hello Adrian Vladu do you think we can close this one: https://github.com/flatcar/Flatcar/issues/1009 ?

I took another look at the missing integrations:

• hc-utils Units for configuring networks: This seems to work out-of-the-box on flatcar

• hc-utils Units for volume automounts: This is basically just a udev rules file, should be easy to get in the oem sysext. One issue I encountered was, that the hc-utils file modified /etc/fstab which is not an option on Flatcar. Not sure how to dynamically generate and persist systemd .mount files here

• Initial Root Password: On Hetzner Cloud its possible to start a server without SSH Key. We generate a root password and show it to the user once. This is then configured on the server through cloud-init chpasswd for the root user

• Root Password Reset: Its possible to reset the root password through the API. This is being handled by qemu-guest-agent. I found that qemu-ga was only installed on the amd64 board, not on arm64. Another issue is, that the message received is for the root user. Not sure if we can just intercept this and always modify the core user instead, or if we want to accept that this does not work.

All of these feature are very much oriented at the beginner users, who are probably not running Flatcar. I do not think we require them, and adding a note about this in the docs should be fine.

In reply to @tormath1:matrix.org
It's up to you, no rush on this but as the initial issue was mentioning the live migration I think it's better to keep it open until it's done?

In reply to @tormath1:matrix.org
It's up to you, no rush on this but as the initial issue was mentioning the live migration I think it's better to keep it open until it's done?

As usual with this kind of question: it depends ™️.
As mentioned in this Brightbox blogpost: https://www.brightbox.com/blog/2024/04/11/flatcar-images/

[...] I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases

A trade-off would be to

As usual with this kind of question: it depends ™️.
As mentioned in this Brightbox blogpost: https://www.brightbox.com/blog/2024/04/11/flatcar-images/

[...] I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases

As usual with this kind of question: it depends ™️.
As mentioned in this Brightbox blogpost: https://www.brightbox.com/blog/2024/04/11/flatcar-images/

[...] I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases

This is one way, marketplace is another... As long as it's documented and properly integrated with the APIs (Terraform, SDK, etc.) it's ok.

As usual with this kind of question: it depends ™️.
As mentioned in this Brightbox blogpost: https://www.brightbox.com/blog/2024/04/11/flatcar-images/

[...] I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases

This is one way of doing things, marketplace is another... As long as it's documented and properly integrated with the APIs (Terraform, SDK, etc.) I would say it's ok.

As usual with this kind of question: it depends ™️.
As mentioned in this Brightbox blogpost: https://www.brightbox.com/blog/2024/04/11/flatcar-images/

[...] I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases

This is one way of doing things, marketplace is another... As long as it's documented and properly integrated with the APIs (Terraform, SDK, etc.) I would say it's ok.

Another question would be: what do I want to propose in my native catalog? Most of the time catalogs are made of general purpose OS (Debian, Ubuntu, Fedora, etc.) I think that would make sense to propose a Container OS in the native catalog.