Port DigitalOcean OEM away from the base Ignition #1142
Comments
github-project-automation
bot
moved this to 📝 Needs Triage
in Flatcar tactical, release planning, and roadmap
pothos
moved this from 📝 Needs Triage
to 🪵Backlog
in Flatcar tactical, release planning, and roadmap
pothos
added
area/sysext
This was referenced Aug 2, 2023
tormath1
moved this from 🪵Backlog
to ⚒️ In Progress
in Flatcar tactical, release planning, and roadmap
1 task
tormath1
moved this from ⚒️ In Progress
to ✅ Testing / in Review
in Flatcar tactical, release planning, and roadmap
|
Closed by flatcar/scripts#1197 |
github-project-automation
bot
moved this from ✅ Testing / in Review
to Implemented
in Flatcar tactical, release planning, and roadmap
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
[email protected].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
[email protected]with a condition forKernelCommandLine=coreos.oem.id=digitaloceanorKernelCommandLine=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.
The text was updated successfully, but these errors were encountered: