Skip to content
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

Port DigitalOcean OEM away from the base Ignition #1142

Closed
pothos opened this issue Aug 2, 2023 · 1 comment
Closed

Port DigitalOcean OEM away from the base Ignition #1142

pothos opened this issue Aug 2, 2023 · 1 comment
Assignees
Labels
area/sysext sysext roadmap

Comments

@pothos
Copy link
Member

pothos commented Aug 2, 2023

Current situation

The DigitalOceam OEM setup uses a base Ignition file that gets merged with the user-passed Ignition config.
Currently the only action is to enable coreos-metadata-sshkeys@.service.

Impact

The setup writes state to the rootfs that is not updated.

Ideal future situation

We don't use the base/default Ignition approach but have a unit in the generic image that enables/runs/depends-on coreos-metadata-sshkeys@.service with a condition for KernelCommandLine=coreos.oem.id=digitalocean or KernelCommandLine=flatcar.oem.id=digitalocean.

Additional information

We could also create a sysext image but that does not make much sense, we already ship KernelCommandLine= OEM units in the base image and the initrd.

A migration action is not really needed for this limited case. But if, we could do it live in flatcar-postinst based on the current and next version being ≥ the major version that introduces the change.

@tormath1
Copy link
Contributor

tormath1 commented Oct 9, 2023

Closed by flatcar/scripts#1197

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/sysext sysext roadmap
Projects
None yet
Development

No branches or pull requests

2 participants