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

Re: OKD 4 - A Modest Proposal





On Fri, Jun 28, 2019 at 4:58 AM Clayton Coleman <ccoleman redhat com> wrote:
> 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
branch switches.

[DC]: wouldn't this be more than just MCD ?e.g - change in installer too [1] to import the v3 spec and work with it 

[1] https://github.com/openshift/installer/blob/master/pkg/asset/ignition/machine/node.go#L7

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

_______________________________________________
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]