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.
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.
Thanks for the response! My immediate question after I read the article yesterday was on the future of Fedora (and RHEL) Atomic.
Both you and the press release mention that CL will be supported for a while, but it's not clear what's going to happen with Atomic. My entirely unscientific and feels-based opinion is that Atomic seems to be getting a little more traction in the Workstation/SilverBlue area at the moment. rpm-ostree is really unique tooling, and I'd hate to see it go away; the more I use it, the more I like it!
At any rate, the market share of CL is probably substantially greater than that of Atomic, but there are those of us who are rolling out k8s clusters based on Atomic. It would be nice to know sooner rather than later if we're wasting our time!
We were looking rather favourably at CoreOS as an enterprise friendly, yet lightweight alternative to OS. LDAP/RBAC/Prometheus are the type of features that we are looking for, on the other hand we have our own build tooling and release process, hence no use for that part of Openshift. I find it hard to recommend using a K8S distribution that has so many batteries included, 75% of which my organization doesn't need or use. Sorry to see Tectonic go.
There is a wonderful little piece of CoreOS that is toolbox[0]. It's not available on Atomic Host. Yes I could install it easily but the point of toolbox is to avoid installing anything on the host system in the first place !
It could easily be forgotten on the side of the road while doing the CoreOS/Atomic fusion work.
So I'm asking you, can you salvage this and integrate it pretty please :) ?
> 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.
As a Gentoo dev and long time user, I've always had a lot of sympathy for CoreOS since the beginning, so when I heard about the RedHat acquisition, I wondered about this. I have to say that I'm saddened to know that Portage will be eventually replaced. It's an excellent package manager.
As an early adopter of CoreOS, paid Tectonic user, I find this distressing, disappointing, and it leaves me wondering where I can turn.
This is the opposite direction of what RedHat should have done.
I was hoping this was a acquisition to move RedHat's technology stack moving forward and instead it's one to move an innovative and solid platform backward.
Acquire, assimilate and kill off competition, just like other RedHat acquisitions before it. :(
"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.
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.
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?
This is why I won't advocate RH and similar vendors. The tech stack churn is too high. If it's not a widely adopted open source platform it's just going to eventually become bought out or die a lonely death with me having to migrate clusters to something else, or hang on to unsupported legacy systems for 10 years. Rather support a Frankenstein's monster of my own design.
It's CoreOS (now called containerLinux) so they probably figure the end user will install containers instead of rpm packages. I haven't added anything to the base containerLinux image while using it, which is probably as intended.
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.
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
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.
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.
[+] [-] jzelinskie|8 years ago|reply
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|8 years ago|reply
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...
[+] [-] davidmr|8 years ago|reply
Both you and the press release mention that CL will be supported for a while, but it's not clear what's going to happen with Atomic. My entirely unscientific and feels-based opinion is that Atomic seems to be getting a little more traction in the Workstation/SilverBlue area at the moment. rpm-ostree is really unique tooling, and I'd hate to see it go away; the more I use it, the more I like it!
At any rate, the market share of CL is probably substantially greater than that of Atomic, but there are those of us who are rolling out k8s clusters based on Atomic. It would be nice to know sooner rather than later if we're wasting our time!
[+] [-] barbul|8 years ago|reply
[+] [-] chrissnell|8 years ago|reply
[+] [-] navaati|8 years ago|reply
There is a wonderful little piece of CoreOS that is toolbox[0]. It's not available on Atomic Host. Yes I could install it easily but the point of toolbox is to avoid installing anything on the host system in the first place !
It could easily be forgotten on the side of the road while doing the CoreOS/Atomic fusion work.
So I'm asking you, can you salvage this and integrate it pretty please :) ?
[0] https://github.com/coreos/toolbox
[+] [-] amadio|8 years ago|reply
As a Gentoo dev and long time user, I've always had a lot of sympathy for CoreOS since the beginning, so when I heard about the RedHat acquisition, I wondered about this. I have to say that I'm saddened to know that Portage will be eventually replaced. It's an excellent package manager.
[+] [-] crad|8 years ago|reply
This is the opposite direction of what RedHat should have done.
I was hoping this was a acquisition to move RedHat's technology stack moving forward and instead it's one to move an innovative and solid platform backward.
Acquire, assimilate and kill off competition, just like other RedHat acquisitions before it. :(
[+] [-] zaat|8 years ago|reply
[+] [-] cbsmith|8 years ago|reply
[+] [-] sytse|8 years ago|reply
[+] [-] actionowl|8 years ago|reply
This is so overloaded with buzz words it took a few attempts to make any sense of it.
[+] [-] erikb|8 years ago|reply
[+] [-] davidmr|8 years ago|reply
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
[+] [-] smarterclayton|8 years ago|reply
It won’t be using chrome OS bits.
Edit: as of now this is what the team is thinking, still lots of room for changes as we refine down.
[+] [-] emmelaich|8 years ago|reply
"Team Silverblue: Fedora as an image and container-based desktop OS"
(using ostree)
[+] [-] puzzle|8 years ago|reply
[+] [-] peterwwillis|8 years ago|reply
[+] [-] state_less|8 years ago|reply
[+] [-] alexandre_m|8 years ago|reply
[+] [-] kev009|8 years ago|reply
[+] [-] smarterclayton|8 years ago|reply
[+] [-] mattdaemon|8 years ago|reply
[+] [-] jzelinskie|8 years ago|reply
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
[+] [-] joshberkus|8 years ago|reply