Re: [PATCH v2 2/4] tests/docker: add support for podman remote access

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jul 09, 2026 at 09:24:12AM -0700, Pierrick Bouvier wrote:
> On 7/9/2026 9:13 AM, Daniel P. Berrangé wrote:
> > On Thu, Jul 09, 2026 at 07:48:14AM -0700, Pierrick Bouvier wrote:
> >> On 2/10/2026 8:35 AM, Daniel P. Berrangé wrote:
> >>> When a developer's environment is already within a podman container it
> >>> is not possible to use 'podman' again to create containers. It will
> >>> usually result in wierd errors such as:
> >>>
> >>>   Error: fatal error, invalid internal status, unable to create a new pause process: cannot re-exec process to join the existing user namespace. Try running "podman system migrate" and if that doesn't work reboot to recover
> >>>
> >>> Podman offers the ability to talk to a daemon outside the container,
> >>> however, which could be leveraged by QEMU.
> >>>
> >>> This can be used by invoking "podman --remote", or equivalently the
> >>> separate "podman-remote" binary:
> >>>
> >>>   https://github.com/containers/podman/blob/main/docs/tutorials/remote_client.md
> >>>
> >>> The current 'podman version' check is insufficient to detect the
> >>> inability to launch containers, so it is replaced with the stronger
> >>> 'podman info' check.
> >>>
> >>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> >>> ---
> >>>  tests/docker/docker.py | 10 ++++++----
> >>>  1 file changed, 6 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/tests/docker/docker.py b/tests/docker/docker.py
> >>> index ff68c7bf6f..9e18b984f4 100755
> >>> --- a/tests/docker/docker.py
> >>> +++ b/tests/docker/docker.py
> >>> @@ -76,14 +76,16 @@ def _guess_engine_command():
> >>>      commands = []
> >>>  
> >>>      if USE_ENGINE in [EngineEnum.AUTO, EngineEnum.PODMAN]:
> >>> -        commands += [["podman"]]
> >>> +        commands += [["podman"], ["podman-remote"], ["podman", "--remote"]]
> >>>      if USE_ENGINE in [EngineEnum.AUTO, EngineEnum.DOCKER]:
> >>>          commands += [["docker"], ["sudo", "-n", "docker"]]
> >>>      for cmd in commands:
> >>>          try:
> >>> -            # docker version will return the client details in stdout
> >>> -            # but still report a status of 1 if it can't contact the daemon
> >>> -            if subprocess.call(cmd + ["version"],
> >>> +            # 'version' is not sufficient to prove a working binary
> >>> +            # for podman. 'info' is a stronger check that is more
> >>> +            # likely to correlate with ability to create containers,
> >>> +            # and required to detect the need for podman remote
> >>> +            if subprocess.call(cmd + ["info"],
> >>>                                 stdout=DEVNULL, stderr=DEVNULL) == 0:
> >>>                  return cmd
> >>>          except OSError:
> >>
> >> Taking a look at why tcg tests are slow to compile, I reached this
> >> commit. It seems like that calling 'podman info' is 5 to 10 times slower
> >> than calling 'podman version'.
> >> Thus, a container run now takes +1s when it was 0.2 before.
> > 
> > Hmmm, but we call 'docker.py probe' in configure and cache the result,
> > so that probe should only be done once.  0.2 vs 1s is just noise in
> > the context of configure.
> > 
> > That you're seeing any negative effects suggests that we've got
> > something not using the cached probe result, which we should fix.
> >
> 
> Not really, docker.py --engine X still calls X info.
> 
> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/docker.py#L675
> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/docker.py#L78
> 
> Maybe the fix is to remove the check if user specified an explicit
> engine. But in this case, there is a problem with podman-remote not
> being detected anymore.
> 
> We can fix this by introducing engine=podman-remote, and skip the check
> if engine is explicitly set.
> What do you think?

Urgh, so i see now we have two code paths / make variables

  RUNC=podman --remote
  CONTAINER_ENGINE=auto

Sometimes we'll invoke docker.py --engine $(CONTAINER_ENGINE)
and sometimes we'll directly invoke $(RUNC).

The result of "probe" cannot be fed back in to "--engine" which
is a bit of a mess. I think the "engine" concept should not be
exposed on the cli, and instead have a "--runc" arg which takes
the full arg(s), since we need probe to report the runc args
for other reasons.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|