On Fri, Jun 28, 2019 at 4:58 AM Clayton Coleman <ccole...@redhat.com> wrote:
> > On Jun 26, 2019, at 1:08 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. > > 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 >
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
