Sorry for missing out the mailer by mistake, not intentional. PSB in blue. On Wed, Jun 26, 2019 at 10:14 PM Daniel Comnea <comnea.d...@gmail.com> wrote:
> > > On Wed, Jun 26, 2019 at 6:09 PM Colin Walters <walt...@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. >> > [DC] : in addition to that i think you need changes to installer/ MCO , or > am i wrong ? > > >> 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). >> > [DC]: curious to understand why it can't be one single FCOS? what other > avenues FCOS do chase will break by having OKD baked in components? > If we are talking about a derivative then i'd go and challenge that maybe > a CentOS CoreOS based on RHCOS is the best bet and that can deprecate > Project Atomic. Doing so imo (i could miss some context here) will reduce > any tension on FCOS charter and will rapidly (hopefully) allow OKD to > become a thing. > >> >> 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 >> >
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
