Repository navigation
proposal for rebasing on Ignition master #402
Description
In trying to adapt for the new live ISO this has involved needing a number of new patches from the ignition-dracut spec2x branch.
The divergence there is nontrivial. We also of course have Ignition master diverging.
I'd like to propose:
- Add support into Ignition git master for using https://github.com/coreos/ign-converter and "upconverting" compatible spec2x code into spec3 (gated behind an off-by-default build tag, don't need it for FCOS)
- Add support into Ignition git master for "delegating" to
/usr/libexec/ignition.spec2if that conversion process fails (again gated on a build tag) - Ship both versions in RHCOS
Then we can switch RHCOS to tracking Ignition and ignition-dracut git master mostly, making our lives involve much less tedious debugging of the initrd. (Or at least, only debugging it once for FCOS)
A side benefit of this is it will largely Just Work for users to pass spec3 to RHCOS directly, but this effort can't replace OpenShift spec 3 conversion because we would need to have updating bootimages first.
Reacted by Christian Glombek
Activity
cgwalters commentedon Mar 6, 2020
(A detail here is I think we still need some kernel patches in RHEL to handle SELinux labeling better, and master ignition+ignition-dracut don't have the legacy code there anymore, but we need to get past that anyways for rootfs reprovisioning)
ashcrow commentedon Mar 9, 2020
This sounds like a good idea to me!
cc @miabbott @darkmuggle @jlebon @arithx
jlebon commentedon Mar 9, 2020
Hmm, I'm wary of pushing this complexity directly in git master Ignition. If this is to make 2 -> 3 transitioning easier, I think it'd make more sense to put that logic closer to where it is needed. E.g. we can just ship both the old and new Ignition in the RHCOS initrd and have a shim determine which one to use?
Though I think this issue is mostly about reducing the maintenance burden in ignition-dracut, right? One thing we could do there is move all the RHCOS specific things to an
overlay.d(i.e. the network-related stuff we don't do in FCOS), and then investigate having git master support both spec 2 and 3. E.g. the mount stage would be a no-op on spec2 (the other big on is--platformvs--oem... maybe we can teach spec2 Ignition to support it as an alias?)cc @bgilbert @lucab
darkmuggle commentedon Mar 9, 2020
I've long advocated for shipping both versions of Ignition and then having something determine which to use. However, the push back on this idea has consistently been that the design of CoreOS is that Ignition defines first boot; supporting multiple versions of Ignition would make the ignition rules squishy.
Given that this is pretty much an RHCOS proposal, I think I like it:
Initially, I liked the Shim idea from @jlebon slightly better than the build flag approach. The appeal of the shim is that Ignition doesn't have to get smarter, and something else deals with it. But @cgwalters idea of using a build flag means the logic is self-contained in Ignition itself.
What do you think about allowing a "fallback delegator" instead of hard-coding
/usr/libexec/ignition.spec2xfor example,/usr/bin/ignition --fallback /usr/libexec/ignition.spec2?openshift-bot commentedon Oct 2, 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting
/remove-lifecycle stale.Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting
/lifecycle frozen.If this issue is safe to close now please do so with
/close./lifecycle stale
travier commentedon Oct 7, 2020
RHCOS will ship with Ignition spec 3 support in 4.6. I think this can be closed now.