A basic thing to keep in mind here is that the existing CoreOS didn't have kickstart and *only* has the PXE-to-Live model for bare metal (with optional persistent install), so there's a lot of overlap going on here. But some of the technology makes sense and is obviously in use by the existing CoreOS community. We're hoping to have a "best of both" message. We don't need to make any hard decisions here right away; the existing Fedora/Atomic and CoreOS will be maintained for a while, but we do hope to unify. On Tue, Apr 17, 2018, at 10:31 AM, Martin Kolman wrote: > > Yeah, Ignittion also seems to me like more like an enhanced Cloudinit > with some > installer bits bolted on & it indeed seems like it could work like a > good cloudinit replacement. One thing that only became a bit clearer to me recently is we actually still need: https://github.com/coreos/coreos-metadata which handles the "processed every boot" aspect that one needs in many cloud environments; however the ignition ~= kickstart still remains, as well as the ssh-key/useradd type overlap between both of them and cloud-init/coreos-metadat. > Yeah, PXE-to-Live is pretty different to how Anaconda does, > we generally differentiate the installation environment and > the target system quite clearly and in this case they are basically > combined together. So if Ignition can do it it makes sense to > me to continu using it for this usecase, at least for the time being. Yeah, given that we don't have tooling that processes a kickstart at boot time. > I think that would work - would Anaconda be expected to parse the > content > of the section or would just writing the content to a file on the target > system > where Ignition will pick it up be enough ? This is a key question. One thing that we're still discussing in the background is whether or not we *really* need ignition to be run in the initramfs or not for our primary use cases. If we don't, a whole lot of things get simpler, it's much more like a better cloud-init that would still run earlier in the boot process (before /var is mounted ideally so you could dynamically configure local OS state, or potentially even replace /). I think for a lot of use cases just writing the file to the target system will be enough, so we don't need Anaconda integration immediately. That said I haven't actually tried this yet. > The git-like aproach rpm-ostree provides seems to me as a much more > advanced & flexible than just using the > relatively primitive and not very flexibile "you have two and exactly > two copies of everything" approach. Yeah; this is still being discussed because it has much higher level ramifications up the stack - the existing CoreOS updater has some sophisticated bits around the https://github.com/google/omaha protocol for example. But we're definitely aiming for "best of both" again. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
