Refactoring code for podman support

[D3vil0p3r]

Description

Refactoring code to support Podman

Point of attention

TO DO

• DockerUtils.py:

  • Currently podman py has a bug to retrieve Mounts attribute values. It causes Exegol to raise the error

    AttributeError: 'str' object has no attribute 'get'
    

    when you start an already existing container. Reported to [BUG] containers.list() returns a list of containers with partial/missing "Mounts" attribute values containers/podman-py#488
  • Adapt the right api.build/remove_volume function to podman if needed: [FEATURE] - Implement "decode" parameter in pull() function and add build/remove_volume function as api/image.py in docker py containers/podman-py#456
  • Podman pull progress bar in Exegol is not dynamic. It occurs because podman pull stream does not show a progress bar as occurs on docker. Reported to [FEATURE] Implement Progress Details in podman pull API as occurs in docker pull API containers/podman#24887
  • [FIXED by client.ping()] Podman connection error is bugged because podman.from_env() seems to return exit status 0 even when podman service is down or uninstalled. It causes to produce AssertionError on Exegol when podman is down instead of running the right exception. Reported in a comment here: fix: Enhance environment connection error handling containers/podman-py#472 . Currently, it can be managed by using client.ping().
  • [FIXED] In podman-py listing and filtering image list not working properly: [BUG] images.list() filter does not work properly containers/podman-py#457
  • [FIXED]

       for img in images:
           # len tags = 0 handle exegol <none> images (nightly image lost their tag after update)
           if len(img.attrs.get('RepoTags', [])) == 0 or \
                   ConstantConfig.IMAGE_NAME in [repo_tag.split(':')[0] for repo_tag in img.attrs.get("RepoTags", [])]:
               result.append(img)
               ids.add(img.id)

    ConstantConfig.IMAGE_NAME in [repo_tag.split(':')[0] for repo_tag in img.attrs.get("RepoTags", [])]: does not manage well cases where user pulled manually exegol image containing also the registry name, for example docker.io/nwodtuhs/exegol. In this scenario, it won't enter in if statement. It is needed to add any to manage cases where locally I have more container images. [Fixed in PR]

• ExegolImage.py:

  • [FIXED]

    def __parseDigest(docker_image: Union[DockerImage, PodmanImage]) -> str:
        """Parse the remote image digest ID.
        Return digest id from the docker object."""
        for digest_id in docker_image.attrs["RepoDigests"]:
            print(digest_id)
            if digest_id.startswith(ConstantConfig.IMAGE_NAME):  # Find digest id from the right repository
                return digest_id.split('@')[1]
        return ""

    As above, cannot enter in if statement in case user pulled manually an image by specifying docker.io. Need to use in instead of startswith. [Fixed in PR]

    Evaluate if it is needed to manage if statements involving ConstantConfig.IMAGE_NAME in other files to manage the presence of prefix docker.io in the image name.

• [FIXED] ExegolController.py - Import podman and manage console.print_exception(show_locals=True, suppress=[docker, requests, git]) to consider podman module too.

• ConstantConfig.py:

  • Review Podman Desktop configuration path for Windows and Mac in case of podman. I would leave this for a different PR, now it is better to focus on Podman py integration
  • Implement the same from docker.types import Mount for podman: [FEATURE] - Implement Mount type containers/podman-py#458 Podman should already manage mount. Just open this PR on podman py upstream Support uppercase mount attributes containers/podman-py#487

[Dramelac]

Hello

Thanks for this PR, it is indeed a more complete approach to integrate podman in a stable way in Exegol.
A few comments:

• for the filter, you should test whether “docker.io/” would not be necessary in the current version of the lib.
• the way DockerUtils tries to load docker or podman doesn't seem right to me, as the original exceptions are caught in the __connect_to_[...] function and therefore never retrieved by the __handle_connection_error function
• your branch is not up to date with the dev version (which should soon be a new release), there are conflicts to manage
• is the fact that the podman lib is the same as the docker lib done on purpose? aren't there risks of divergence at times?

Thanks in any case for your help with this integration, there will be a lot of testing to do to make sure everything is compatible with podman and exegol before officially integrating it into the project, but it's certainly a very good starting point.

[D3vil0p3r]

I'll try to give answer

• for the filter, you should test whether “docker.io/” would not be necessary in the current version of the lib.

FIXED on podman-py upstream. I wouldn't suggest to add docker.io on IMAGE_NAME constant. I would keep it as is because docker does not add that registry name, and adding it could break some if statements.

• the way DockerUtils tries to load docker or podman doesn't seem right to me, as the original exceptions are caught in the __connect_to_[...] function and therefore never retrieved by the __handle_connection_error function

FIXED. PS: in the future DockerUtils can be renamed as ContainerUtils.

• your branch is not up to date with the dev version (which should soon be a new release), there are conflicts to manage

FIXED. Meanwhile I try to align it with dev branch over time.

• is the fact that the podman lib is the same as the docker lib done on purpose? aren't there risks of divergence at times?

Not all functions are the same. The risk of divergence depends on how we will adapt podman on Exegol. On this PR we are not using Docker Py functions to manage podman daemon, but we are invoking original Podman Py libs to manage its daemon.

Overall, before to continue to work on this PR, I think we need to wait for those issues/PRs I opened on Podman Py project.