I'm sure that project would benefit from your feedback and information on what looks like a bug. What did upstream Podman community say? Did they understand your issues? Were they able to reproduce the error? Were they able to fix it?
I'd like to reiterate that the Podman and Buildah projects were started in order to address business needs for specific risk averse customers. The upstream work we had started with Docker still could not meet those requirements and so investment was started in alternative OCI based approaches that were essentially daemonless and were taking advantage of other enhancements in namespaces and CGroups.
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.
Fair points. Work is ongoing with a podman-compose. I haven't used it myself. Most of the routing work for our initial users are focused on is around Kubernetes/okd/OpenShift (and not Swarm) and so that's where those routing issues are solved.
I know someone worked on a Ubuntu build but I'm not sure who is maintaining that. It would be a great place for people to contribute.
Thanks for all the feedback. I will try to address many of the comments in a follow up blog. I will also try to address some of them here in reply to the comments.
First I want to mention a couple of things:
1) My blog didn't recognize the diversity of meanings for "Docker" to the Docker community. This is a problem when there is confusion over Docker company, Docker community, Docker as a collective of products, Docker as a single command line project/product. My blog was specifically focused on Docker CLI users. The Docker command line tool that so many of us grew to love. To say I "don't know our care how people use containers" is an unfortunate conclusion to make. I'm sorry of my restricted use made it seem that way. I will say I wrote all of the original Docker CLI manual pages. So I can claim a very deep knowledge of the Docker CLI. I had to test almost every aspect of the CLI in order to write those manual pages. As a result I filed several bugs too. But I do understand the the Docker CLI is just one part of the tooling that many Docker community users take advantage of. My definition of Docker was limited in my blog. It did not address projects like docker-compose etc.
2) It is unfair to say that Red Hat employees set out to destroy/ruin/whatever Docker. Very early on we wanted to help the Docker community. Red Hat provided a lot of validation to the Docker community by jumping on board and providing a lot of technical expertise and including it in RHEL and OpenShift. People like Dan Walsh and others tried very hard to explain both enterprise features required by risk averse users and also how to build a sustainable inclusive community model. Unfortunately much of our enthusiasm to help make Docker successful, based on our proven track record, fell on deaf ears. Perhaps their was s suspicion that were were looking after our own self interests but it really was a genuine effort to share our experiences in the community. Our open source first approach is always in the interest of the community and our customers and we know that that benefits us too. We know that strong inclusive communities benefit everyone. We sometimes get this wrong. But most times it works out - consider out move from our OpenShift cartridges technology to Docker. We didn't try to kill Docker, we knew it had the right approach. We wanted to make it better through open source community contributions. And we invested in Docker very heavily. Eventually some of our customer concerns with security could not be met with Docker's daemon approach (btw dockerd or containerd) and so wehad to address those requirements.
I have continued to talk about the value of Docker to the container community and how they revolutionized the industry because of their unique value add on Linux containers.
3) There are areas that Podman still needs to address. Some hare been worked on - podman-compose and a Mac client etc. Plenty of work to be done. If you're interested then please consider contributing to Podman (libpod) Podman-Compose etc. at https://github.com/containers