On Tue, 2018-04-17 at 09:38 -0400, Colin Walters wrote: > We're working on merging some of the CoreOS <https://coreos.com/> technologies with > the Fedora/Atomic technologies. One thing that came up is they have > a new take on system bootstrap called Ignition: > https://github.com/coreos/ignition > > We're investigating making this work in Fedora as well: > https://pagure.io/atomic-wg/issue/450 > > There's a fair amount of overlap with the role of Anaconda in > terms of system provisioning. Some of this is actually similar > to the overlap between kickstart + cloud-init I posted previously: > > https://www.redhat.com/archives/anaconda-devel-list/2014-December/msg00008.html > > We're currently thinking Ignition should take over from cloud-init (though the details > there are still TBD). Its ability to do partitioning makes it a lot > closer to kickstart[1]. 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 I'd floated in some of our discussions was that conceptually > one could write a kickstart-to-ignition transpiler just like the > "clc-to-ignition" transpiler: > https://coreos.com/os/docs/latest/overview-of-ct.html > I'm not sure if this would be valuable versus writing ct since most > people are going to be starting "fresh" I suspect, but the fact > that we could helps understand the concepts here I think. > > Probably where the biggest overlap is around baremetal provisioning; > CoreOS supports a "PXE-to-Live" model for servers: > https://coreos.com/os/docs/latest/booting-with-ipxe.html > as well as a script to install to disk persistently: > https://coreos.com/os/docs/latest/installing-to-disk.html > > The latter path is like the existing Anaconda+kickstart > path; so where things intersect most strongly here is what we do > with those two paths. I'd suggest that for PXE-to-Live which we > don't currently productize that we focus on Ignition. 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. > > > For persistent installations - I think we'd clearly need to support > kickstarts, but it's probably useful to look at a path where > Anaconda includes support for Ignition; perhaps it something like > a %ignition config stanza in kickstart? 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 ? We could also make sure the ignition package is installed on the target system when when the %ignition section shows up in kickstart (we already do that for various kickstart commands such as realm, firewall, etc.). Also alternatively if you wanted some more advanced configuration done during the installation or wanted to provide a configuration GUI/TUI, Anaconda can be extended via addons: https://rhinstaller.github.io/anaconda-addon-development-guide/ Addons can have their own kickstart section and can (but don't have to) provide TUI & GUI screens. > > [1] They even support partitioning the root filesystem > but I think that only works for the existing CoreOS with the dual-partition > /usr A/B approach; what I call "classic" Fedora with yum as well as > the existing Atomic with rpm-ostree both have the operating system > content in /, not in separate partitions. This might be a bit unrelated to current topic, but what are the plans with supporting the CoreOS A/B approach ? 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. It seems to me that compared to A/B ostree makes it possibly to have an arbitrary number of system states available and should also be more space efficient (unless CoreOS deduplicates the A/B copies somehow). > > > _______________________________________________ > 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
