----- Original Message ----- > From: "Colin Walters" <walters@xxxxxxxxxx> > To: anaconda-devel-list@xxxxxxxxxx > Sent: Friday, April 20, 2018 4:40:16 PM > Subject: Re: Adopting CoreOS Ignition into Fedora+derivatives ecosystem > > 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. Yep, that definitely sounds like a good plan. :) > > 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. Technically speaking, Initial Setup[0] does that - it reads the kickstart Anaconda generated during installation and proceeds accordingly. There are a couple expectations though: - IS is run on the first boot of a system after installation (or on arm from pre-prepared image) - the run is generally one-off and IS is disabled once it has done it's thing - IS runs on the system after switchroot (eq. not in initrd) I don't think there was ever a use-case considered where IS would run on every boot and act as a system configuration agent. [0] https://github.com/rhinstaller/initial-setup > > > 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. BTW, we do regenerate initrd during installation so if you had Ignition as a Dracut module, it could pick up the configuration file from the rootfs when the initrd is regenerated. (That's why we regenerate the initrd during installation - so that all packages and any configuration changes done by Anaconda are in place when Dracut generates the initrd image.) > > > 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. Interesting! That's indeed more sophisticated than just a plain A/B system. > But we're definitely aiming for "best of both" again. Yet again sounds like a good plan. :) > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
