> On Jun 26, 2019, at 1:08 PM, Colin Walters <walters verbum org> wrote:
> On Thu, Jun 20, 2019, at 5:20 PM, Clayton Coleman wrote:
>> Because the operating system integration is so critical, we need to
>> make sure that the major components (ostree, ignition, and the kubelet)
>> are tied together in a CoreOS distribution that can be quickly
>> refreshed with OKD - the Fedora CoreOS project is close to being ready
>> for integration in our CI, so that’s a natural place to start. That
>> represents the biggest technical obstacle that I’m aware of to get our
>> first versions of OKD4 out (the CI systems are currently testing on top
>> of RHEL CoreOS but we have PoCs of how to take an arbitrary ostree
>> based distro and slot it in).
> The tricky thing here is...if we want this to work the same as OpenShift 4/OCP
> with RHEL CoreOS, then what we're really talking about here is a *derivative*
> of FCOS that for example embeds the kubelet from OKD. And short term
> it will need to use Ignition spec 2. There may be other things I'm forgetting.
Or we have a branch of mcd that works with ignition 3 before the main
[DC]: wouldn't this be more than just MCD ?e.g - change in installer too  to import the v3 spec and work with it
Yes, but possibly not a large change or one that is a “use ignition3” flag or similar.
I don’t know that it has to work exactly the same, but obviously the
closer the better.
> Concretely for example, OKDFCOS (to use the obvious if unwieldy acronym)
> would need to have its own uploaded "bootimages" (i.e. AMIs, PXE media etc)
> that are own its own version number/lifecycle distinct from (but derived from)
> FCOS (and OKD).
Or it just pivots. Pivots aren’t bad.
> This is completely possible (anything is in software) but the current team is
> working on a lot of things and introducing a 3rd stream for us to maintain would
> be a not at all small cost. On the other hand, the benefit of doing so (e.g.
> early upstream kernel/selinux-policy/systemd/podman integration testing
> with kubernetes/OKD) might be worth it alone.
> dev mailing list
> dev lists openshift redhat com
dev mailing list
dev lists openshift redhat com