Why is there no documentation explaining the preference of podman over docker?

[nbelakovski-mssm]

Despite the fact that docker is clearly more popular than podman, there is hardly any mention of docker on the project website or anywhere else.

I don't have a problem with podman, I'd just like to see some transparency from the project saying clearly that docker isn't and won't be supported (if indeed that is the case) and perhaps some rationale as to what led to this decision.

It sounds like maybe Red Hat is trying to use cockpit project to promote podman. I honestly don't have a problem with that, I just want to see some clear information on the website as to docker support or lack thereof. Right now readers have to read between the lines to understand the state of docker support.

[martinpitt]

From our team's point of view there isn't much magic here. We are a small team and we get dozens of "add support for XXX" that we can't/won't do. podman is in RHEL (and all distros which we support), docker isn't, so we concentrate on the former. That doesn't and shouldn't stop anyone from making a cockpit-docker page -- forking cockpit-podman would be a good start, and we actively encourage others to make their own plugins We offer starter-kit and a documented API for that.

We will not create documentation about an indefinitely big list of things which we can't/won't support, that'd be a maintenance headache. We document the things which we do support.

[steve4835]

This seems inaccurate at best and disingenuous at worst, as Cocker did support Docker in the not-so-distant past, and the support was dropped. Your reply is phrased as if it was never supported. I tend to agree with OP, it seems as if Red Hat is using cockpit to promote podman over docker.

[nbelakovski-mssm]

it seems as if Red Hat is using cockpit to promote podman over docker.

And to reiterate, there's nothing wrong with that, but docker is the 800 lb Gorilla in the room and the response frames it as if I'm asking for a AAA game to be supported on Linux. Something in the docs like "why we don't support docker natively" and a link to an explanation of the advantages of podman over docker would be welcome. It would probably get more people into cockpit which could then provide an audience for conversion to podman. I'm actually switching to podman on one project for security reasons, but like steve said the provided response seems disingenuous.

[martinpitt]

Sure, someone could also start from the old cockpit-docker page. But that would make little sense -- it's much less effort to port current cockpit-podman to the docker API (which is like 95% the same anyway) than replaying 5 years of design, UI, node, build system, OS compatibility, and docker/podman development.

I fully stand by my reply, and there is nothing disingenious about it from my perspective. Yes, cockpit did support docker until RHEL 7 because RHEL did. Now RHEL and Fedora doesn't any more, and that's that. If you want to interpret this as disingenious, 🤷‍♂️ .

[nbelakovski-mssm]

@martinpitt The issue is not whether or not cockit supports docker, it's about clarifying that position instead of expecting people to read between the lines.

We are a small team and we get dozens of "add support for XXX" that we can't/won't do

We will not create documentation about an indefinitely big list of things which we can't/won't support, that'd be a maintenance headache. We document the things which we do support.

These are the parts that seem disingenuous. You make it sound like docker is some niche thing with a small community, and that if you document why you don't support docker that you'd have to also document why you don't support BSD, Amiga, Commodore, etc. You can't honestly expect us to believe that you've never heard of docker or that you're not aware that it's the dominant container technology in use today.

Again, this is not a request for the project to support docker.

[martinpitt]

Don't put words in my mouth. I never claimed that I didn't hear about docker -- to the contrary, I even pointed you to the old code. But that's not the point -- there are a zillion podman features that cockpit-podman doesn't support, nor does Cockpit talk (any more) to kubernetes, kata containers, LXC, nspawn, or a million other technologies.

We are not going to create a comprehensive list of things which we don't support. Nobody does that ever.