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? Thanks, Kevin ________________________________ From: Clayton Coleman [ccole...@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....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote: 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. 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. 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. 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. #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. 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. 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? 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). Thanks, Kevin
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
