
Roadmap for CoreOS Integration with Red Hat OpenShift - davidmr
https://www.redhat.com/en/about/press-releases/red-hat-unveils-roadmap-coreos-integration-red-hat-openshift
======
jzelinskie
I'm a PM and engineer at CoreOS/Red Hat -- feel free to ask any questions and
I'll do my best to answer.

In the next few months, you should see an OpenShift that is built upon the
same upgrade system as Tectonic which allows for more incremental buy-in to
OpenShift PaaS functionality and a Linux distribution that leverages Ignition
and immutability to provide the minimal environment needed to run
Kubernetes/containers.

My understanding is that Container Linux as is will be supported for years,
but we will also be creating a new distro, RH CoreOS, that replaces the Gentoo
build system with Fedora tooling. This shouldn't change much for users as they
don't interact with the build system; they just consume the results of said
system. I'd liken this scenario to the relationship between CentOS and RHEL,
which are both maintained by Red Hat. Some details have yet to shake out; for
example, I personally don't know if the resulting distro will leverage rpm-
ostree, but we already have internal proof-of-concepts running OpenShift with
Tectonic components on top of Container Linux.

Please voice your opinions here and now! Nothing is set in stone and we're
listening for the community to weigh in on these decisions as well.

~~~
fefefe21
One of the main reasons we use CoreOS is that it ships stable and _state of
the art_ features from the _latest_ Linux kernels, so features and
infrastructure like eBPF are available and can be used without problems. RHEL
kernels (e.g. speaking of RHEL7) on the other hand are ancient and heavily
outdated, and only backport some of the newer features from upstream kernels,
so user space making use of it cannot be run anymore preventing latest
innovation (or killing Linux kernel innovation through supporting bypasses
like DPDK).

Oracle's RHEL clone on the other hand ship their UEK kernel which is a recent,
commercially supported kernel based on (almost) latest upstream. There, the
situation is at least better than with native RHEL, but I truly hope Red Hat
has an answer to that with brand new Linux kernel's on RH CoreOS side. Please
don't let innovation coming from the kernel die by dictating ancient RHEL
kernels to majority of users. CoreOS enables innovation, please make sure it
continues to do so.

By the way, there was a good summary on this point with regards to RHEL kernel
considered harmful here: [https://medium.com/@sargun/red-hat-enterprise-linux-
consider...](https://medium.com/@sargun/red-hat-enterprise-linux-considered-
harmful-c95af86062f4)

~~~
Fuzzy_Logic
RHEL is an LTS distro. Red Hat also develops Fedora as a bleeding edge distro,
and there is plenty of innovation going on there.

[https://getfedora.org/](https://getfedora.org/)

~~~
noir_lord
I switched from Ubuntu to Fedora on my development machines and it has been
amazing.

Stability is superb and a lot of the niggles I had with Ubuntu just went away.

Fedora Cinnamon is damn close to perfect as a development desktop for my
needs. I literally can't think of anything I'd improve outside of its multi-
monitor support (it's fine with fixed monitors but plugging my 4K on
displayport on the ThinkPad requires some finessing but so did windows).

------
actionowl
"CoreOS technology to combine with Red Hat OpenShift to drive hybrid cloud-
native services, will power fully-automated Linux container platform stack,
from the operating system to application services, across the hybrid cloud"

This is so overloaded with buzz words it took a few attempts to make any sense
of it.

~~~
erikb
Sounds cooler than "We will also create the AWS VMs for you, just give us the
credentials", though.

------
davidmr
The bits about the OpenShift integration are interesting I guess, but buried
about halfway down is the news that they intend CoreOS' Container Linux to
supplant their existing Fedora/RHEL Atomic Host, and Brandon Philips from
CoreOS says that they're be continuing to base it around Ignition[0]

I'm genuinely surprised at this. RH has put a ton of work into rpm-ostree for
a long time. I guess there's a chance they'll meld it somehow with Ignition
and Container Linux's Chrome OS bits when they turn it into Red Hat Container
Linux or whatever it'll be called, but it's surprising to see Red Hat
supporting a Linux distro not based of of RPMs and installed with
kickstart/anaconda.

[0]
[https://twitter.com/BrandonPhilips/status/993880972583092225](https://twitter.com/BrandonPhilips/status/993880972583092225)

~~~
puzzle
It's not clear to me if e.g. the Container Linux system will be still built
using Gentoo's emerge or the RH tools. You seem to discount the latter, but I
guess it depends on what they really mean with "based on Fedora and Red Hat
Enterprise Linux sources". Are they going to rebuild e.g. the kernel using
emerge, but from RH's source tarballs and collection of patch sets?

~~~
smarterclayton
Initially its going to be based on RHEL so we can quickly ramp up. Over time
it’s very likely we get more aggressive with RH CoreOS and newer kernels, but
those are all details being worked on. It’s very important for us to be able
to benefit from existing engineering investments in the community and within
RHEL, but there’s a lot of excitement about taking what CoreOS proved could be
compelling and reinforcing that with the Red Hat engineering teams. Stay tuned
for more.

------
kev009
The PR is written a bit ambiguously, is the Gentoo based container Linux going
to be maintained or will it move to EL/Fedora?

~~~
smarterclayton
Maintained. A new offering based on RHEL will be initially targeted for the
supported scenarios under openshift while we work with the communities on how
they want to evolve.

~~~
merb
So will there be a path to upgrade CoreOS to RedHat Container Linux?

~~~
cgwalters
If you're using Tectonic in particular, we're certainly aiming to have a nice
path. Although there are a lot of details in the term "upgrade" \- it may
require reprovisioning, but a lot of the idea of carrying forward Ignition is
that any early OS customization you've made still applies.

If you're running a Kubernetes cluster, while Red Hat CoreOS will support
automatic inplace updates just like existing CL, I'd say it's best practice to
do periodic reprovisioning to flush out extra node state. For example in RHEL
7.5 we switched from devicemapper to overlayfs, but existing instances don't
get automatically transitioned. If you're using k8s reprovisioning works well
as all the containers just move off and then back on.

------
mattdaemon
What are your plans for rkt? It’s great alternative in a docker-dominated
ecosystem and much more solid architecture but haven’t seen much progress
lately. Doesn’t seem to be getting a lot of love

~~~
jzelinskie
Red Hat is backing CRI-O for an alternative OCI runtime.

While we did pave the way for creating alternatives for Docker in Kubernetes,
CoreOS never quite got rkt to 100% stability in Kubernetes. Personally, I love
a lot of things about rkt, but the project's ultimate goal was to have
standards, regardless of whether or not it was AppC.

If you're still interested in rkt (it's great tech that we still use to this
day to run kubelet for all Tectonic clusters), I recommended chatting to the
awesome folks at Kinvolk[0]. They maintain rkt alongside CoreOS and support
customers using it in production.

[0]: [https://kinvolk.io](https://kinvolk.io)

~~~
zapita
May I ask why you're pushing cri-o instead of the more mature containerd? All
the technical explanations I got were hand-wavy and unconvincing.

The only explanation I see is that containerd is backed by Docker, a
competitor of Red Hat, and that business rivalry overrode engineering common
sense. Now we have to suffer yet another "war of the container runtimes", as
if the original dockerd vs rkt wasn't painful enough.

Can you share your perspective on this?

~~~
smarterclayton
cri-o has exactly three foundational principles:

* be exactly what Kubernetes needs and no more

* work with OCI-standard runtimes (runc, gvisor, runv, kata, clearcontainers, etc) in order to accomplish the above

* integrate well with Linux (use systemd for process management, bias towards tools that already exist in Linux or improve existing tools) to accomplish the above

I don’t think there’s a war. Use what you like. OpenShift specifically
supports exact versions of cri-o and Docker 1.13 in order to provide the best
Kubernetes experience and ensure clusters always work. There are pros and cons
to all container runtimes, but it wasn’t a business decision, it was a
technical decision for us.

cri-o is supported for production workloads under OpenShift 3.9 and RHEL 7.5
and we use it on our largest Online clusters. We see better memory use and
predictable latency for containers than Docker and containerd for Kubernetes
in general.

We don’t want anyone to feel like they can’t use other runtimes, but being
Kubernetes-first has always been a goal we didn’t want to compromise on.

~~~
zapita
Your answer is 99% techno-marketing bullshit, but you still delivered the
kernel of a credible explanation: _systemd_.

It makes perfect sense now. cri-o, being "daemonless", reinforces the central
role of systemd in orchestrating system resources, whereas containerd, being a
daemon, weakens it. I can see how Red Hat architects would not love the idea,
given the importance of systemd in the RHEL/Openshift stack.

Thanks for enlightening me, if only accidentally.

~~~
davidmr
There’s no call to be so rude. The RH/CoreOS people here are acting in good
faith, I think they’re being exceptionally helpful, and they don’t even need
to be answering questions at all.

------
joshberkus
For anyone reading this thread who is at Red Hat Summit, we will have a
Container Linux/Atomic BOF at 1pm today (May 10), in the BOF area on the 2nd
floor.

