Re: OKD 4 - A Modest Proposal
On Jun 28, 2019, at 3:38 AM, Daniel Comnea wrote: On Fri, Jun 28, 2019 at 4:58 AM Clayton Coleman wrote: > > On Jun 26, 2019, at 1:08 PM, Colin Walters 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 Yes, but possibly not a large change or one that is a “use ignition3” flag or similar. > 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
Re: OKD 4 - A Modest Proposal
On Fri, Jun 28, 2019 at 4:58 AM Clayton Coleman wrote: > > On Jun 26, 2019, at 1:08 PM, Colin Walters 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
Re: OKD 4 - A Modest Proposal
> On Jun 26, 2019, at 1:08 PM, Colin Walters 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. 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
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 wrote: > > > On Wed, Jun 26, 2019 at 6:09 PM Colin Walters 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
Re: OKD 4 - A Modest Proposal
In Fedora Atomic, it was trivial to build a custom ostree image. I would hope the same is available for the FCOS model as well. On Wed, Jun 26, 2019 at 1:36 PM Colin Walters wrote: > > > > On Wed, Jun 26, 2019, at 1:10 PM, Colin Walters wrote: > > > 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. > > It was pointed out to me that there is also some relevant discussion in this > issue: > https://github.com/coreos/fedora-coreos-tracker/issues/93 > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev -- Michael Gugino Senior Software Engineer - OpenShift mgug...@redhat.com 540-846-0304 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: OKD 4 - A Modest Proposal
On Wed, Jun 26, 2019, at 1:10 PM, Colin Walters wrote: > 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. It was pointed out to me that there is also some relevant discussion in this issue: https://github.com/coreos/fedora-coreos-tracker/issues/93 ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: OKD 4 - A Modest Proposal
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
