7 ms·

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 th

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.

sytse 8y ago
The operator framework seems really useful. Do you expect that eventually it or something like it will become part of Kubernetes?
- jzelinskie 8y ago
  We're collaborating with the kubebuilder[0] project upstream, which is a subproject of SIG API Machinery that focuses on generating the best scaffolding for controllers. Myself and some Googlers also proposed creating a SIG focusing on platform extensions to Kubernetes, such as operators tooling[1]. The steering committee is currently not convinced that it merits a dedicated SIG, despite the many projects in the wild experimenting without organization. We're fully committed to taking well understood, community-accepted opinions from our tooling and upstreaming the work, if the community can agree on that aspect of the framework. A great example of this is the Application Definition Working Group, which has leveraged many ideas from our Operator Lifecycle Manager; our CRDs are practically the same! Now that things are open source, we should see things like these converge entirely. [0]: https://github.com/kubernetes-sigs/kubebuilder https://github.com/kubernetes-sigs/kubebuilder [1]: https://groups.google.com/d/msg/kubernetes-dev/RgwIQ9Dii-I/Q1_tTTnwBgAJ https://groups.google.com/d/msg/kubernetes-dev/RgwIQ9Dii-I/Q...
  - sytse 8y ago
    Awesome, thanks for the overview.
- devkulkarni 8y ago
  Agree that the operator framework looks useful. Here is an article that I wrote recently analyzing the Operator Framework: https://medium.com/@cloudark/analyzing-value-of-operator-framework-for-kubernetes-community-5a65abc259ec https://medium.com/@cloudark/analyzing-value-of-operator-fra... As to whether this or other similar projects will become part of Kubernetes core, my guess is probably there will be resistance to it as it will mean choosing one particular way of how Kubernetes can be extended over others. And this will be against the overall philosophy of Kubernetes that components in it are optional and pluggable[1]. On the other hand, some standardization will mostly likely evolve around the end-user experience of consuming multiple Operators in a single Kubernetes Cluster. [1] https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ https://kubernetes.io/docs/concepts/overview/what-is-kuberne...
chrissnell 8y ago
Will there always be a free and maintained version of Container Linux available?
- chrissnell 8y ago
  I guess that's a no?
  - tpetry 8y ago
    At the discussion of the acquisation months ago someone from RH stated that coreos will still be free ;)
- joshberkus 8y ago
  "always" is a really long time.
zaat 8y ago
Will Quay Enterprise will be open sourced?
- jzelinskie 8y ago
  Red Hat open sources everything and Quay is no exception. I expect it to be open sourced by the end of the year or early Q1. Quay has a few additional [time consuming] internal processes it has to go through, as it is a totally new product at Red Hat.
  - zaat 8y ago
    Thanks for the response, this is a very happy outcome of the deal.
  - jkbuster 8y ago
    This is very exciting! Quay is the best registry I’ve worked with by far. But, I’d love an open source version I could run on-prem
barbul 8y ago
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.
- jzelinskie 8y ago
  Being from CoreOS, I understand your sentiment. Part of our long term integration goal with OpenShift is to try and package up all of its components as Operators that can be optionally installed with our Operator Lifecycle Manager[0]. This is the software that powered Tectonic's Open Cloud Services. In addition, we're rolling out an installer based on the Tectonic installer. The end result should be an installation process similar to Tectonic and Kubernetes cluster running very few services, until you decide to install additional Operators for the functionality you want. [0]: https://github.com/operator-framework/operator-lifecycle-manager https://github.com/operator-framework/operator-lifecycle-man...
  - Terretta 8y ago
    Good to hear. It’s been awesome to see this pattern go from idea to community best practice.
  - barbul 8y ago
    Thanks for your response, it is good to know that these things are being considered.
- Terretta 8y ago
  Agreed. Preferred the Tectonic approach and roadmap based on CoreOS founder Alex Polvi‘s mission to secure the Internet: https://coreos.com/blog/why-we-started-coreos https://coreos.com/blog/why-we-started-coreos When at my new gig we suggested RH should understand the sec and ops value of CoreOS thinking, we didn’t mean take them off the market. :-) Alex, Brandon, still want what you were building.
davidmr 8y ago
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!
- jzelinskie 8y ago
  I'm not sure of the all the details related to Atomic, but my understanding is that you're correct in its smaller marketshare. Unlike Container Linux, I personally don't know how much time we're going to continue to maintain the distribution. I know there is public information somewhere; I'm going to fire off an email to get more information so that I can clarify this post. Going forward RHEL and Red Hat CoreOS are going to be the official distributions supported for running OpenShift. RHEL will be for users that need to install software on the hosts themselves manually and CoreOS will be the preferred immutable host that expects all software running at the cluster-level. Running OpenShift on Container Linux or Atomic will be like running RHEL RPMs on CentOS -- it'll pretty much work fine, but I don't think you can call up Red Hat if you get into trouble. rpm-ostree is super cool. The engineers working on the OS are still trying to figure out how to bring everything together, but we understand how important this technology is. I know this is the hill where the Atomic engineers will die on, so if there's going to be anything from Atomic in CoreOS, it's going to be this, haha.
- cgwalters 8y ago
  The answer to this splits across the Fedora/RHEL sides. For people using RHEL Atomic Host today (and RHEL) with OpenShift, we obviously want a good transition to Red Hat CoreOS. That gets into some details though of provisioning and what types of customization is being done today. Similar concerns apply to Tectonic+CL users. My message on the community side (Fedora and existing CL) is - don't panic, you have some time. And a lot of us want to support a broad array of use cases. Since you mention rpm-ostree, one thing I'd point you to is some work we did on changing the Container Linux update operator to talk to it: https://github.com/ashcrow/container-linux-update-operator/ https://github.com/ashcrow/container-linux-update-operator/
fefefe21 8y ago
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-considered-harmful-c95af86062f4 https://medium.com/@sargun/red-hat-enterprise-linux-consider...
- Fuzzy_Logic 8y ago
  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/
  - fefefe21 8y ago
    You are missing the point. It's not at all about Fedora itself here. What I was trying to say is that today CoreOS (even in) stable is using Linux kernel 4.14.32 (https://coreos.com/releases/ https://coreos.com/releases/) and therefore enabling deployments to use the latest and greatest features, performance optimisations and innovation from the Linux kernel community in enterprise environments. Going back to RHEL kernel would be a major step backwards preventing a wide user base from access to what CoreOS enables them to do today. I genuinely hope that CoreOS folks at RH don't give up on continuing to deliver this sort of innovation. That is all what I was trying to get across.
  - noir_lord 8y ago
crad 8y ago
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. :(
- Proven 8y ago
  Of course. You probably expected something like this might happen when you decided to use CoreOS... I wish there was a Debian (or better, Devuan) based system that could just work well, but it can’t happen without big money... I doubt Tectonic would have survived without this acquisition.
- jzelinskie 8y ago
  I'm genuinely interested why you believe this is the case. Can you point to anything in specific about the converged stack that makes you feel uneasy? From the CoreOS perspective, OpenShift will literally become the new version Tectonic, which was work from before the acquisition, but with the ability to install additional OpenShift components as optional Operators.
  - crad 8y ago
    The move to Fedora on its a huge negative from my perspective. If you're just dropping OpenShift and rebranding Tectonic as OpenShift, I guess that's ok, but I'm still stuck dealing with RedHat (the organization) which in my 20+ years of being a Linux user has largely been more negative than positive.
    - jzelinskie 8y ago
      The tooling to create the immutable image is what is changing from Mantle (our Gentoo and ChromeOS toolchain) to Fedora tools. From the consumer perspective, you will not see any RPMs or package managers in our distribution. If you have not built a custom image of Container Linux yourself, you weren't even aware this software existed.
navaati 8y ago
Hi. 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 https://github.com/coreos/toolbox
- jzelinskie 8y ago
  I don't think you need to worry about toolbox going anywhere as it's already Fedora based, haha!
  - navaati 8y ago
    Oh I had forgotten that ! But I'm not worrying about fedora inside my toolbox but about my toolbox inside fedora ^^
    - cgwalters 8y ago
      Thanks for bringing this up, this one had dropped off my radar. I do think that the simple concept of having `toolbox` installed by default is a powerful one, and while we should revisit some of the details I'd say we should carry this one forward. Have you built much scripting up on top of it, or is it just having it available for interactive use?
      - navaati 8y ago
        Oh thanks ! Not much scripting, just a personalised image on Docker Hub and an alias on my dev machine to push "navaati/toolbox" in the .toolboxrc on machines (but that's just a small convenience).
- fatherlinnux 8y ago
  In Fedora, there is the Fedora Tools container [1], in RHEL, there is the RHEL Tools container. I don't envision either of those going away because they allow you to do all kinds of fancy stuff including things that require kernel compatibility, like SystemTap, core dumps, etc. I am a product manager for containers/rhel/CoreOS at Red Hat, and I very much foresee a similar container for Red Hat CoreOS which will provide similar functionality for troubleshooting kernel, and user space (aka other containers) problems. [1]: https://www.projectatomic.io/blog/2015/09/introducing-the-fedora-tools-image-for-fedora-atomic-host/ https://www.projectatomic.io/blog/2015/09/introducing-the-fe... [2]: https://developers.redhat.com/blog/2015/03/11/introducing-the-rhel-container-for-rhel-atomic-host/ https://developers.redhat.com/blog/2015/03/11/introducing-th...
cbsmith 8y ago
Damn, I'm going to miss the Gentoo build system.
amadio 8y ago
> 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.
- Conan_Kudo 8y ago
  Container Linux never shipped Portage in the distribution, and Red Hat CoreOS will not ship Yum/DNF either.

sytse 8y ago

The operator framework seems really useful. Do you expect that eventually it or something like it will become part of Kubernetes?

jzelinskie 8y ago
We're collaborating with the kubebuilder[0] project upstream, which is a subproject of SIG API Machinery that focuses on generating the best scaffolding for controllers. Myself and some Googlers also proposed creating a SIG focusing on platform extensions to Kubernetes, such as operators tooling[1]. The steering committee is currently not convinced that it merits a dedicated SIG, despite the many projects in the wild experimenting without organization. We're fully committed to taking well understood, community-accepted opinions from our tooling and upstreaming the work, if the community can agree on that aspect of the framework. A great example of this is the Application Definition Working Group, which has leveraged many ideas from our Operator Lifecycle Manager; our CRDs are practically the same! Now that things are open source, we should see things like these converge entirely. [0]: https://github.com/kubernetes-sigs/kubebuilder https://github.com/kubernetes-sigs/kubebuilder [1]: https://groups.google.com/d/msg/kubernetes-dev/RgwIQ9Dii-I/Q1_tTTnwBgAJ https://groups.google.com/d/msg/kubernetes-dev/RgwIQ9Dii-I/Q...
- sytse 8y ago
  Awesome, thanks for the overview.
devkulkarni 8y ago
Agree that the operator framework looks useful. Here is an article that I wrote recently analyzing the Operator Framework: https://medium.com/@cloudark/analyzing-value-of-operator-framework-for-kubernetes-community-5a65abc259ec https://medium.com/@cloudark/analyzing-value-of-operator-fra... As to whether this or other similar projects will become part of Kubernetes core, my guess is probably there will be resistance to it as it will mean choosing one particular way of how Kubernetes can be extended over others. And this will be against the overall philosophy of Kubernetes that components in it are optional and pluggable[1]. On the other hand, some standardization will mostly likely evolve around the end-user experience of consuming multiple Operators in a single Kubernetes Cluster. [1] https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ https://kubernetes.io/docs/concepts/overview/what-is-kuberne...

chrissnell 8y ago

Will there always be a free and maintained version of Container Linux available?

chrissnell 8y ago
I guess that's a no?
- tpetry 8y ago
  At the discussion of the acquisation months ago someone from RH stated that coreos will still be free ;)
joshberkus 8y ago
"always" is a really long time.

zaat 8y ago

Will Quay Enterprise will be open sourced?

jzelinskie 8y ago
Red Hat open sources everything and Quay is no exception. I expect it to be open sourced by the end of the year or early Q1. Quay has a few additional [time consuming] internal processes it has to go through, as it is a totally new product at Red Hat.
- zaat 8y ago
  Thanks for the response, this is a very happy outcome of the deal.
- jkbuster 8y ago
  This is very exciting! Quay is the best registry I’ve worked with by far. But, I’d love an open source version I could run on-prem

barbul 8y ago

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.

jzelinskie 8y ago
Being from CoreOS, I understand your sentiment. Part of our long term integration goal with OpenShift is to try and package up all of its components as Operators that can be optionally installed with our Operator Lifecycle Manager[0]. This is the software that powered Tectonic's Open Cloud Services. In addition, we're rolling out an installer based on the Tectonic installer. The end result should be an installation process similar to Tectonic and Kubernetes cluster running very few services, until you decide to install additional Operators for the functionality you want. [0]: https://github.com/operator-framework/operator-lifecycle-manager https://github.com/operator-framework/operator-lifecycle-man...
- Terretta 8y ago
  Good to hear. It’s been awesome to see this pattern go from idea to community best practice.
- barbul 8y ago
  Thanks for your response, it is good to know that these things are being considered.
Terretta 8y ago
Agreed. Preferred the Tectonic approach and roadmap based on CoreOS founder Alex Polvi‘s mission to secure the Internet: https://coreos.com/blog/why-we-started-coreos https://coreos.com/blog/why-we-started-coreos When at my new gig we suggested RH should understand the sec and ops value of CoreOS thinking, we didn’t mean take them off the market. :-) Alex, Brandon, still want what you were building.

davidmr 8y ago

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!

jzelinskie 8y ago
I'm not sure of the all the details related to Atomic, but my understanding is that you're correct in its smaller marketshare. Unlike Container Linux, I personally don't know how much time we're going to continue to maintain the distribution. I know there is public information somewhere; I'm going to fire off an email to get more information so that I can clarify this post. Going forward RHEL and Red Hat CoreOS are going to be the official distributions supported for running OpenShift. RHEL will be for users that need to install software on the hosts themselves manually and CoreOS will be the preferred immutable host that expects all software running at the cluster-level. Running OpenShift on Container Linux or Atomic will be like running RHEL RPMs on CentOS -- it'll pretty much work fine, but I don't think you can call up Red Hat if you get into trouble. rpm-ostree is super cool. The engineers working on the OS are still trying to figure out how to bring everything together, but we understand how important this technology is. I know this is the hill where the Atomic engineers will die on, so if there's going to be anything from Atomic in CoreOS, it's going to be this, haha.
cgwalters 8y ago
The answer to this splits across the Fedora/RHEL sides. For people using RHEL Atomic Host today (and RHEL) with OpenShift, we obviously want a good transition to Red Hat CoreOS. That gets into some details though of provisioning and what types of customization is being done today. Similar concerns apply to Tectonic+CL users. My message on the community side (Fedora and existing CL) is - don't panic, you have some time. And a lot of us want to support a broad array of use cases. Since you mention rpm-ostree, one thing I'd point you to is some work we did on changing the Container Linux update operator to talk to it: https://github.com/ashcrow/container-linux-update-operator/ https://github.com/ashcrow/container-linux-update-operator/

fefefe21 8y ago

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-considered-harmful-c95af86062f4 https://medium.com/@sargun/red-hat-enterprise-linux-consider...

Fuzzy_Logic 8y ago
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/
- fefefe21 8y ago
  You are missing the point. It's not at all about Fedora itself here. What I was trying to say is that today CoreOS (even in) stable is using Linux kernel 4.14.32 (https://coreos.com/releases/ https://coreos.com/releases/) and therefore enabling deployments to use the latest and greatest features, performance optimisations and innovation from the Linux kernel community in enterprise environments. Going back to RHEL kernel would be a major step backwards preventing a wide user base from access to what CoreOS enables them to do today. I genuinely hope that CoreOS folks at RH don't give up on continuing to deliver this sort of innovation. That is all what I was trying to get across.
- noir_lord 8y ago

crad 8y ago

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. :(

Proven 8y ago
Of course. You probably expected something like this might happen when you decided to use CoreOS... I wish there was a Debian (or better, Devuan) based system that could just work well, but it can’t happen without big money... I doubt Tectonic would have survived without this acquisition.
jzelinskie 8y ago
I'm genuinely interested why you believe this is the case. Can you point to anything in specific about the converged stack that makes you feel uneasy? From the CoreOS perspective, OpenShift will literally become the new version Tectonic, which was work from before the acquisition, but with the ability to install additional OpenShift components as optional Operators.
- crad 8y ago
  The move to Fedora on its a huge negative from my perspective. If you're just dropping OpenShift and rebranding Tectonic as OpenShift, I guess that's ok, but I'm still stuck dealing with RedHat (the organization) which in my 20+ years of being a Linux user has largely been more negative than positive.
  - jzelinskie 8y ago
    The tooling to create the immutable image is what is changing from Mantle (our Gentoo and ChromeOS toolchain) to Fedora tools. From the consumer perspective, you will not see any RPMs or package managers in our distribution. If you have not built a custom image of Container Linux yourself, you weren't even aware this software existed.

navaati 8y ago

Hi. 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 https://github.com/coreos/toolbox

jzelinskie 8y ago
I don't think you need to worry about toolbox going anywhere as it's already Fedora based, haha!
- navaati 8y ago
  Oh I had forgotten that ! But I'm not worrying about fedora inside my toolbox but about my toolbox inside fedora ^^
  - cgwalters 8y ago
    Thanks for bringing this up, this one had dropped off my radar. I do think that the simple concept of having `toolbox` installed by default is a powerful one, and while we should revisit some of the details I'd say we should carry this one forward. Have you built much scripting up on top of it, or is it just having it available for interactive use?
    - navaati 8y ago
      Oh thanks ! Not much scripting, just a personalised image on Docker Hub and an alias on my dev machine to push "navaati/toolbox" in the .toolboxrc on machines (but that's just a small convenience).
fatherlinnux 8y ago
In Fedora, there is the Fedora Tools container [1], in RHEL, there is the RHEL Tools container. I don't envision either of those going away because they allow you to do all kinds of fancy stuff including things that require kernel compatibility, like SystemTap, core dumps, etc. I am a product manager for containers/rhel/CoreOS at Red Hat, and I very much foresee a similar container for Red Hat CoreOS which will provide similar functionality for troubleshooting kernel, and user space (aka other containers) problems. [1]: https://www.projectatomic.io/blog/2015/09/introducing-the-fedora-tools-image-for-fedora-atomic-host/ https://www.projectatomic.io/blog/2015/09/introducing-the-fe... [2]: https://developers.redhat.com/blog/2015/03/11/introducing-the-rhel-container-for-rhel-atomic-host/ https://developers.redhat.com/blog/2015/03/11/introducing-th...

cbsmith 8y ago

Damn, I'm going to miss the Gentoo build system.

amadio 8y ago

> 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.

Conan_Kudo 8y ago
Container Linux never shipped Portage in the distribution, and Red Hat CoreOS will not ship Yum/DNF either.