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

Re: OKD 4 - A Modest Proposal



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 dani gmail com> wrote:


On Wed, Jun 26, 2019 at 6:09 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.
[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

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