Refactoring code for podman support

[D3vil0p3r]

Description

Refactoring code to support Podman

Point of attention

TO DO

• DockerUtils.py:

  • Adapt the right api.pull/build/remove_volume function to podman: https://github.com/containers/podman-py/issues/456
  • In podman-py listing and filtering image list not working properly: https://github.com/containers/podman-py/issues/457

  • 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:

  • 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.

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

• ConstantConfig.py:

  • Review Desktop path for Windows and Mac in case of podman
  • Implement the same from docker.types import Mount for podman: https://github.com/containers/podman-py/issues/458

[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.

Already tried, it is not an issue related to the input string, but an issue at code level. And 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

It can be changed. I did that proposal but I'm sure there are better ways to explore. 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

Probably because in the last days Exegol devs submitted new commits after the time I opened my PR. We can manage them once the PR is ready.

• 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.