3 ms·

Docker architecture isn't reflective of that blog post anymore. Considering containerd is now the runtime, the arguments outlined initially for "why Docker isn

Docker architecture isn't reflective of that blog post anymore. Considering containerd is now the runtime, the arguments outlined initially for "why Docker isn't good in Redhats eyes" are no longer valid in the case of how the argument is laid out. I don't feel Docker was incented to do anything based on RH's blog posts. I worked for Docker and the joke internally was how hard RH went out of their way in a "me too" fashion to compare their homegrown products, that weren't offering any upside and offering a lot of replacements that weren't nearly with feature parity. Dan Walsh was the butt of many jokes with his tirades about how one should never say Docker, and in turn probably exposed more people to Docker than he turned away. High security? As I understand it RH doesn't have a way to guarantee containers that are requested to be run have been signed by appropriate release control. Docker can. Since you're a RH employee maybe you can share the innovative reasoning why RH removed all Docker bits (that they could) from the OS and started telling customers Docker on RHEL wasn't supported? Sounds very anti-innovative to me, but would love your feedback.

freedomben 7y ago
Thanks for sharing your perspective, I appreciate it! > Since you're a RH employee maybe you can share the innovative reasoning why RH removed all Docker bits (that they could) from the OS and started telling customers Docker on RHEL wasn't supported? Sounds very anti-innovative to me, but would love your feedback. I don't work on any of the podman/buildah/etc stuff so I can't speak about any of that as an employee since I have no special insight. (I just disclosed my employer previously so people can judge for themselves if my opinions/thoughts reflect a conflict of interest). But speaking just as a fan of docker (and of podman too), I actually agree that removing the docker bits from RHEL isn't cool. I've used Fedora as my workstation for over 10 years now and were I still working for various start ups I'd have a harder time since I used Docker for containerizing and deploying our apps. I'd probably have to run Ubuntu in a VM so I could use "real" docker, which would make me sad. As I understand it tho it wasn't a decision they reached lightly. There were compatibility issues (such as cgroups v2) that would have held back other things. Sorry I can't be any more specific. I just don't know enough about the background. I do think the real or perceived animosity tho is counter-productive, and I agree the Dan Walsh stuff was a bit on the silly side. I mean, "docker" and "containers" really did become synonymous in many developer minds, but I don't see why that was a big deal (and it certainly wasn't unfairly earned). Can you comment about the Docker closed API stuff? As I understand it, Docker (the company) never released the API to the community (or CNCF, etc) and that is part of the reason why RH didn't want to support it for reasons of legal ambiguity and not wanting to be on the hook for a specific vendor's implementation. I think it's a shame there isn't more collaboration between the RH people and Docker people. The rift may not be reparable now, but I hope we don't end up with a huge divide in the community where all RH/Fedora people have to use podman and Ubuntu/Debian people use Docker, and each OS doesn't support the either. That would be bad for everyone. Sorry this comment is going on forever, but lastly since you worked for docker, thank you! Docker revolutionized the way I did things and has made my life better. Regardless what happens, Docker will have a warm place in my heart.
ipbabble 7y ago
I regret to inform you that you are not understanding this point regarding the daemon correctly. The containerd process is a replacement for the dockerd. It's just a new daemon I apologize I didn't address this clearly in the blog - I was a bit flippant in using dockerd only when I should have mentioned containerd. I agree that when you're working within the Docker Swarm type community there was probably little incentive to to anything based on RHs blog post. I'm very sorry to hear that Dan Walsh was the butt of many jokes at Docker. Dan Walsh did so much for the Docker community at the start - SELinux work being just one area of his many important contributions to making Docker successful. We removed it because we have decided to support one OCI based container toolset in RHEL. Just like we switched from our home grown open source cartridge approach and dropped it to Dockers homegrown based approach in RHEL and OpenShift we had to do the same. We did this with our Gear versus Kubernetes versus Swarm versus Mesos approach. All of these are really good technologies. I myself advocated some support for Mesos at one time. It was about engineering and support focus. It wasn't about killing innovation. It's about focus. This is certainly my personal opinion of our business decision but it is shared by others I work with.

freedomben 7y ago

Thanks for sharing your perspective, I appreciate it! > Since you're a RH employee maybe you can share the innovative reasoning why RH removed all Docker bits (that they could) from the OS and started telling customers Docker on RHEL wasn't supported? Sounds very anti-innovative to me, but would love your feedback. I don't work on any of the podman/buildah/etc stuff so I can't speak about any of that as an employee since I have no special insight. (I just disclosed my employer previously so people can judge for themselves if my opinions/thoughts reflect a conflict of interest). But speaking just as a fan of docker (and of podman too), I actually agree that removing the docker bits from RHEL isn't cool. I've used Fedora as my workstation for over 10 years now and were I still working for various start ups I'd have a harder time since I used Docker for containerizing and deploying our apps. I'd probably have to run Ubuntu in a VM so I could use "real" docker, which would make me sad. As I understand it tho it wasn't a decision they reached lightly. There were compatibility issues (such as cgroups v2) that would have held back other things. Sorry I can't be any more specific. I just don't know enough about the background. I do think the real or perceived animosity tho is counter-productive, and I agree the Dan Walsh stuff was a bit on the silly side. I mean, "docker" and "containers" really did become synonymous in many developer minds, but I don't see why that was a big deal (and it certainly wasn't unfairly earned). Can you comment about the Docker closed API stuff? As I understand it, Docker (the company) never released the API to the community (or CNCF, etc) and that is part of the reason why RH didn't want to support it for reasons of legal ambiguity and not wanting to be on the hook for a specific vendor's implementation. I think it's a shame there isn't more collaboration between the RH people and Docker people. The rift may not be reparable now, but I hope we don't end up with a huge divide in the community where all RH/Fedora people have to use podman and Ubuntu/Debian people use Docker, and each OS doesn't support the either. That would be bad for everyone. Sorry this comment is going on forever, but lastly since you worked for docker, thank you! Docker revolutionized the way I did things and has made my life better. Regardless what happens, Docker will have a warm place in my heart.

ipbabble 7y ago

I regret to inform you that you are not understanding this point regarding the daemon correctly. The containerd process is a replacement for the dockerd. It's just a new daemon I apologize I didn't address this clearly in the blog - I was a bit flippant in using dockerd only when I should have mentioned containerd. I agree that when you're working within the Docker Swarm type community there was probably little incentive to to anything based on RHs blog post. I'm very sorry to hear that Dan Walsh was the butt of many jokes at Docker. Dan Walsh did so much for the Docker community at the start - SELinux work being just one area of his many important contributions to making Docker successful. We removed it because we have decided to support one OCI based container toolset in RHEL. Just like we switched from our home grown open source cartridge approach and dropped it to Dockers homegrown based approach in RHEL and OpenShift we had to do the same. We did this with our Gear versus Kubernetes versus Swarm versus Mesos approach. All of these are really good technologies. I myself advocated some support for Mesos at one time. It was about engineering and support focus. It wasn't about killing innovation. It's about focus. This is certainly my personal opinion of our business decision but it is shared by others I work with.