On Wed, Jul 24, 2019 at 12:45 PM Fox, Kevin M <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
