All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH v2 2/4] tests/docker: add support for podman remote access
Date: Thu, 9 Jul 2026 17:13:36 +0100	[thread overview]
Message-ID: <ak_IsMGkkMY8wERc@redhat.com> (raw)
In-Reply-To: <cbc2e0d7-72d6-4350-a906-e0003e8b5964@oss.qualcomm.com>

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.

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



  parent reply	other threads:[~2026-07-09 16:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10 16:35 [PATCH v2 0/4] tests/docker: improve detection of docker/podman Daniel P. Berrangé
2026-02-10 16:35 ` [PATCH v2 1/4] tests/docker: improve handling of docker probes Daniel P. Berrangé
2026-02-10 16:35 ` [PATCH v2 2/4] tests/docker: add support for podman remote access Daniel P. Berrangé
2026-03-02  7:51   ` Thomas Huth
2026-07-09 14:48   ` Pierrick Bouvier
2026-07-09 15:40     ` Daniel P. Berrangé
2026-07-09 15:55       ` Pierrick Bouvier
2026-07-09 16:01         ` Daniel P. Berrangé
2026-07-09 16:04           ` Pierrick Bouvier
2026-07-09 16:15             ` Daniel P. Berrangé
2026-07-09 16:13     ` Daniel P. Berrangé [this message]
2026-07-09 16:24       ` Pierrick Bouvier
2026-07-10  8:06         ` Daniel P. Berrangé
2026-07-10 11:47           ` Alex Bennée
2026-07-10 11:52             ` Daniel P. Berrangé
2026-07-10 18:20               ` Pierrick Bouvier
2026-07-13  8:32                 ` Daniel P. Berrangé
2026-07-13 16:01                   ` Pierrick Bouvier
2026-02-10 16:35 ` [PATCH v2 3/4] tests/docker: allow display of docker output Daniel P. Berrangé
2026-03-02  8:07   ` Thomas Huth
2026-07-10 11:36   ` Alex Bennée
2026-02-10 16:35 ` [PATCH v2 4/4] gitlab: ensure docker output is always displayed in CI Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ak_IsMGkkMY8wERc@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@oss.qualcomm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.