Feature: run/exec --docker-compatible-check

[bbros-dev]

/kind feature

Description
As a user of 3rd-party tools that use Docker in scripts
I want to easily see the changes need to be made to replace docker with podman
I want to check docker compatibility without downloading or building images
I want a report that solves incompatibilities
I want a report that shows potential issues
I want a report that shows solutions for potential issues

Steps to reproduce the issue:
Describe the results you received:

Currently no such helper exists.

Describe the results you expected:

Ideally the report would show for known incompatibilities:
A. The podman option/argument that replaces a particular docker option/argument
Ideally the report would show for potential issues:
A. A description of the possible issue
B. A description of the solution

Example workflow

1. Given a docker command:

   /usr/bin/docker run -i -t --rm \
     --user 1000:1000
     --volume /dev:/dev \
     --volume /usr/local/src/firecracker:/firecracker:z \
     --env OPT_LOCAL_IMAGES_PATH=/firecracker/build \
     --env PYTHONDONTWRITEBYTECODE=1 \
     fcuvm/dev:v16 bash

2. When I change to this podman command

   /usr/bin/podman run --docker-compatibility-check \
     -i -t --rm \
     --user 1000:1000
     --volume /dev:/dev \
     --volume /usr/local/src/firecracker:/firecracker:z \
     --env OPT_LOCAL_IMAGES_PATH=/firecracker/build \
     --env PYTHONDONTWRITEBYTECODE=1 \
     fcuvm/dev:v16 bash

3. I receive some such report:

Incompatibilities: None
Potential Issues: 2

Potential Issue 1:
    The use of `--volume dev:dev` can lead to failure when run rootless and/or privilege-free.
    The failure can be an error report about accessing /dev/console.
Solution: 
    See podman.io/solution/device-tree-sharing

Potential Issue 2:
    The use of `--user NNN:MMM` can lead to failure when run rootless and/or privilege-free.
    The failure can be an error about operating system denied access to a folder or file.
Solution: 
    Add the podman specific option `--userns=keep-id`. 
    For more details see https://podman.io/solution/user-name-space

Additional information you deem important (e.g. issue happens only occasionally):

This issue arises immediately for any user switching from Docker to Podman.

Output of podman version:

$ podman version
Version:      2.0.0
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 10:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

Package info (e.g. output of rpm -q podman or apt list podman):

$ apt list podman
Listing... Done
podman/now 2.0.0-3 amd64 [installed,local]

Additional environment details (AWS, VirtualBox, physical, etc.):

Any

[rhatdan]

I am not sure how this would work. The goal is for both to work exactly the same. But we do have to deal with running docker as root versus running podman as non-root, which caused both of your issues.

[bbros-dev]

No worries. Just thought it'd be a useful feature to encourage users who only occasionally dip into Docker but have it scattered throughout their scripts as they have written them from time-to-time.

But we do have to deal with running docker as root versus running podman as non-root

I think root and root + --privileged changes how you use containers and changing that usage can be painful for anyone wanting to switch, e.g. --volume dev:dev.

Happy to close this. Leave it up to you.

[rhatdan]

Yes I wish we had a simpler solution for the --volume /dev:/dev problem.
@giuseppe Any ideas on this one. Could crun ignore the error if /dev/console already exists?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@giuseppe Any ideas?

[giuseppe]

sorry for the delay. I think the best we can offer is a way to mount a new devpts: #7209

In this way we can do something like:

$ bin/podman run -ti --rm -v /dev:/dev  --mount type=devpts,target=/dev/pts fedora echo it works
it works

It would be easy to silently do it, but I prefer if it done explicitly and have control on it