Major Summary
When you use podman-docker that is emulating docker via podman CLI. Kn workflow plugin behaves as the docker is installed and uses its docker path to spin up the container instead of podman path. This is likely caused by the CLIs use of github.com/docker/docker/client library that is not able to distinquish this as it uses the client.FromEnv option makes the library check the DOCKER_HOST environment variable that will be set when your local installation is podman-docker based.
When running the command:
kn workflow run
The container never gets created and an the creation times out with on the one unexpected entry in logs:
✅ Checking if Docker is available... - Docker is running ⏳ Starting your SonataFlow project in dev mode... 🔎 Warming up SonataFlow containers (registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0), this could take some time...Created container with ID 59a75080ec4d2733f3934d3e0086d27fce56ab993cd7c1be3f755dbb0f279430 ⏳ Starting your container and SonataFlow project... find: ‘./src/main/resources’: Permission denied <--- ERROR, Unexpected
Environment
Fedora 41, podman-docker-5:5.4.0-1.fc41.noarch installed using DNF
Steps to reproduce
- Install podman-docker using DNF - sudo dnf install podman-docker
- Run - kn workflow create
- Run - cd new-project
- Run - kn workflow run
Actual results
✅ Checking if Docker is available... - Docker is running ⏳ Starting your SonataFlow project in dev mode... 🔎 Warming up SonataFlow containers (registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:1.36.0), this could take some time...Created container with ID 59a75080ec4d2733f3934d3e0086d27fce56ab993cd7c1be3f755dbb0f279430 ⏳ Starting your container and SonataFlow project... find: ‘./src/main/resources’: Permission denied
Expected results
No permission denied to `./src/main/resources`
- CLI uses podman path when `podman-docker` is installed
- CLI correctly determines it is using podman
- (optional) consider that we could also fix this by adding `--container-runner=podman|docker` as a flag to CLI features
Workaround
When using podman-docker unset the DOCKER_HOST variable.
Use regular installation of podman.
User regular installation of docker.
Testing
This was found during test day after I have migrated to new laptop and our department was told to not use docker and I set up podman-docker. QE deems this as low prio as we have our testing images for OS machine setup either with docker or podman and creating new one for podman-docker would not be trivial and the value brought is low compared to costs.