Re: Adopting CoreOS Ignition into Fedora+derivatives ecosystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux