Yeah, There is the question what it is now, and the question what it potentially should be. I'm asking more from a where should it go standpoint.
Right now, k8s distro's are very much in the early linux distro days. Here's how to get a base os going. Ok, now your on your own to deploy anything on it. Download tarball, build it, install it, write init script, etc. If you look a the total package list in the modern linux distro, the os level stuff is usually a very small percentage of the software in the distro.
These days we've moved on so far from "the distro is a kernel" that folks even talk about running a redhat, a fedora, or a centos container. Thats really #4 level stuff only.
olm is like yum. a tool to install stuff. So kind of a #3 tool. Its the software packaging itself, mysql, apache, etc. that is also part of the distro that is mostly missing I think. a container is like an rpm. one way to define a linux distro is a collection of prebuilt/tested/supported rpms for common software.
In the linux os today, you can start from "I want to deploy a mysql server" and I trust redhat to provide good software, so you go and yum install mysql. I could imagine similarly OKD as a collection of software to deploy on top of a k8s, where there is an optional, self hosting OS part (1-3) the same way Fedora/Centos can be used purely #4 with containers, or as a full blown os+workloads.
Sure, you can let the community build all their own stuff. Thats possible in linux distro's today too and shouldn't be blocked. But it misses the point why folks deploy software from linux distro's over getting it from the source. I prefer to run mysql from redhat as apposed to upstream because of all the extras the distro packagers provide.
Not trying to short change all the hard work in getting a k8s going. okd's doing an amazing job at that. That's really important too. But so is all the distro work around software packaging, and thats still much more in its infancy I think. We're still mostly at the point where we're debating if thats the end users problem.
The package management tools are coming around nicely, but not so much yet the distro packages. How do we get a k8s distro of this form going? Is that in the general scope of OKD, or should there be a whole new project just for that?
The redhat container catalog is a good start too, but we need to be thinking all the way up to the k8s level.
Should it be "okd k8s distro" or "fedora k8s distro" or something else?
From: Clayton Coleman [ccoleman redhat com]
Sent: Wednesday, July 24, 2019 10:31 AM
To: Fox, Kevin M
Cc: Michael Gugino; users; dev
Subject: Re: Follow up on OKD 4
On Wed, Jul 24, 2019 at 12:45 PM Fox, Kevin M <Kevin Fox pnnl gov> wrote:
That's interesting that you'd say that. I think kube today is like "install a kernel with bash and serial port magic", whereas OpenShift 4 is "here's a compose, an installer, a disk formatter, yum, yum repos, lifecycle, glibc, optional packages, and sys utils". I don't know if you can extend the analogy there (if you want to use EKS, you're effectively running on someone's VPS, but you can only use their distro and you can't change anything), but definitely a good debate.
I think the analogy I've been using is that openshift is a proper distro in the sense that you don't take someone's random kernel and use it with someone else's random glibc and a third party's random gcc, but you might not care about the stuff on top. The things in 3 for kube feel more like glibc than "which version of Firefox do I install", since a cluster without ingress isn't very useful.
Really? I don't think that's true at all - I'd flip it around and say it's 85% booted, with 15% user space today. I'd probably draw the line at auth, ingress, and olm as being "the top of the bottom". OpenShift 4 is 100% about making that bottom layer just working, rather than being about OLM up.
In the proposal before it was definitely 1-3 (which is the same as the OCP4 path). If you only care about 4, you're talking more about OLM on top of Kube, which is more like JBoss or something like homebrew on Mac (you don't upgrade your Mac via home-brew, but you do consume lots of stuff out there).