On Wed, Feb 21, 2018, at 12:34 PM, Chris Negus wrote:

> In my mind, this means that someone trying out vanilla Kubernetes will 
> start with some OS outside of the Fedora/RHEL/CentOS ecosystem. My 
> question is, is it okay to let this content die? Or should we encourage 
> some way to still manually use Kubernetes on Fedora (Atomic or not)?

This is a pretty deep question with a lot of implications and history involved.
Let me start by stating something that's fairly obvious: Kubernetes is pretty
popular!  There are multiple "distros" of Kubernetes now, including now *two*
products owned by Red Hat.

My personal opinion (now) is that we are primarily producing a base operating 
system; we need to
support these different Kubernetes distributions; as well as non-Kubernetes

Including Kubernetes directly in AH was clearly a historical mistake, one that
we are just finally digging ourselves out from.  Part of the issue here is that
in Atomic we are introducing *two* entirely new ways to deliver software;
via system containers as well as package layering now.  And Kubernetes could
be done via both.

In practice, I think system containers for Kubernetes make a lot of sense 
then you get a natural decoupling of the base OS from your container service; 
live at different cadences.  But it's been a challenge because it's quite 
from all of the other ways to run Kube.

Kubernetes *also* is an excellent use case for the Fedora "Modularity" effort - 
just one version of Kubernetes included in the "Everything" repository doesn't 
sense when upstream supports multiple.

The way I would describe this then is that we are providing technology that is 
to support this use case, and we also need to be participating in issues that 
the OS/Kubernetes boundary (for example: SELinux policy, host update 
So I think our current efforts at having system containers for upstream 
Kubernetes maintained by
"us" are indeed the right approach - we need to ensure the basics work.  Ideally
of course we have more people gaining traction/buy-in in the upstream 
Kubernetes community.
In practice I think a whole lot of that is mostly "non-Atomic" CentOS/RHEL 
using RPMs
or just plain dropping binaries in /opt - hopefully we can get some of the 
community using the technologies we've developed here.  But it's tricky because
we have other Kubernetes distributions like OpenShift which are also a primary 
use case.

Anyways another important thing here is: we need to *clearly* distinguish the 
scenario from the "production" use case.  For the "dev/test" case there's 
as well as `oc cluster up` which I use a lot (and a major bonus of using Linux 
a desktop including Fedora Atomic Workstation is that you can `oc cluster up` 
on metal and avoid virt overhead).

Reply via email to