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. 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). 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 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
