Ah, this raises an interesting discussion I've been wanting to have for a while.
There are potentially lots of things you could call a distro.
Most linux distro's are made up of several layers:
1. boot loader - components to get the kernel running
2. kernel - provides a place to run higher level software
3. os level services - singletons needed to really call the os an os. (dhcp, systemd, dbus, etc)
4. prebuilt/tested, generic software/services - workload (mysql, apache, firefox, gnome, etc)
For sake of discussion, lets map these layers a bit, and assume that the openshift specific components can be added to a vanilla kubernetes. We then have
1. linux distro (could be k8s specific and micro)
2. kubernetes control plane & kubelets
3. openshift components (auth, ingress, cicd/etc)
4. ? (operators + containers, helm + containers, etc)
openshift use to be defined as being 1-3.
As things like ake/eks/gke make it easy to deploy 1-2, maybe openshift should really become modular so it focuses more on 3 and 4.
As for having something that provides a #1 that is super tiny/easy to maintain so that you can do #2 on top easily, I'm for that as well, but should be decoupled from 3-4 I think. Should you be able to switch out your #1 for someone elses #1 while keeping the rest? That's the question from previous in the thread.
#4 I think is very important and while the operator framework is starting to make some inroads on it, there is still a lot of work to do to make an equivalent of the 'redhat' distro of software that runs on k8s.
A lot of focus has been on making a distro out of k8s. but its really mostly been at the level of, how do I get a kernel booted/upgraded. I think the more important distro thing #4 is how do you make a distribution of prebuilt, easy to install software to run on top of k8s. Redhat's distro is really 99% userspace and a bit of getting the thing booted. Its value is in having a suite of prebuilt, tested, stable, and easily installable/upgradable software with a team of humans that can provide support for it. The kernel/bootloader part is really just a means to enable #4. No one installs a kernel/os just to get a kernel. This part is currently lacking. Where is the equivalent of Redhat/Centos/Fedora for #4.
In the context of OKD, which of these layers is OKD focused on?
From: dev-bounces lists openshift redhat com [dev-bounces lists openshift redhat com] on behalf of Clayton Coleman [ccoleman redhat com]
Sent: Wednesday, July 24, 2019 9:04 AM
To: Michael Gugino
Cc: users; dev
Subject: Re: Follow up on OKD 4
On Wed, Jul 24, 2019 at 10:40 AM Michael Gugino <mgugino redhat com> wrote:
I tried FCoS prior to the release by using the assembler on github.
That’s feedback that’s probably something you should share in the fcos forums as well. I will say that I find the OCP + RHEL experience unsatisfying and doesn't truly live up to what RHCOS+OCP can do (since it lacks the key features like ignition and immutable hosts). Are you saying you'd prefer to have more of a "DIY kube bistro" than the "highly opinionated, totally integrated OKD" proposal? I think that's a good question the community should get a chance to weigh in on (in my original email that was the implicit question - do you want something that looks like OCP4, or something that is completely different).
That’s even more dramatic a change from OKD even as it was in 3.x. I’d be happy to see people excited about reusing cvo / mcd and be able to mix and match, but most of the things here would be a huge investment to build. In my original email I might call this the “I want to build my own distro" - if that's what people want to build, I think we can do things to enable it. But it would probably not be "openshift" in the same way.
MCD is really tied to the OS. The idea of a generic MCD seems like it loses the value of MCD being specific to an OS.
I do think there are two types of components we have - things designed to work well with kube, and things designed to work well with "openshift the distro". The former can be developed against Kube (like operator hub / olm) but the latter doesn't really make sense to develop against unless it matches what is being built. In that vein, OKD4 looking not like OCP4 wouldn't benefit you or the components.
A big part of openshift 4 is "we're tired of managing machines". It sounds like you are arguing for "let people do whatever", which is definitely valid (but doesn't sound like openshift 4).