qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] tests/docker: Allow passing --network option when buildi


From: Alex Bennée
Subject: Re: [RFC PATCH] tests/docker: Allow passing --network option when building images
Date: Tue, 19 Jan 2021 15:58:32 +0000
User-agent: mu4e 1.5.7; emacs 28.0.50

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Jan 19, 2021 at 03:40:50PM +0100, Philippe Mathieu-Daudé wrote:
>> On 1/19/21 3:20 PM, Daniel P. Berrangé wrote:
>> > On Tue, Jan 19, 2021 at 02:40:13PM +0100, Philippe Mathieu-Daudé wrote:
>> >> On 1/19/21 12:27 PM, Alex Bennée wrote:
>> >>> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>> >>>
>> >>>> When using the Docker engine, build fails because the container is
>> >>>> unable to resolve hostnames:
>> >>>>
>> >>>>   $ make docker-image-debian-s390x-cross NETWORK=host ENGINE=docker
>> >>>>     BUILD   debian10
>> >>>>   #6 9.679 Err:1 http://deb.debian.org/debian buster InRelease
>> >>>>   #6 9.679   Temporary failure resolving 'deb.debian.org'
>> >>>>   #6 16.69 Err:2 http://security.debian.org/debian-security 
>> >>>> buster/updates InRelease
>> >>>>   #6 16.69   Temporary failure resolving 'security.debian.org'
>> >>>>   #6 22.69 Err:3 http://deb.debian.org/debian buster-updates InRelease
>> >>>>   #6 22.69   Temporary failure resolving 'deb.debian.org'
>> >>>>   #6 22.74 W: Failed to fetch 
>> >>>> http://deb.debian.org/debian/dists/buster/InRelease  Temporary failure 
>> >>>> resolving 'deb.debian.org'
>> >>>>   #6 22.74 W: Failed to fetch 
>> >>>> http://security.debian.org/debian-security/dists/buster/updates/InRelease
>> >>>>   Temporary failure resolving 'security.debian.org'
>> >>>>   #6 22.74 W: Failed to fetch 
>> >>>> http://deb.debian.org/debian/dists/buster-updates/InRelease  Temporary 
>> >>>> failure resolving 'deb.debian.org'
>> >>>>   #6 22.74 W: Some index files failed to download. They have been
>> >>>>   ignored, or old ones used instead.
>> >>>
>> >>> I'm confused by this one as it currently works for me. That said I
>> >>> thought the actual behaviour was meant to be networking is enabled by
>> >>> default and explicitly disabled by the run step (which shouldn't be
>> >>> pulling extra stuff down).
>> >>>
>> >>> This was last tweaked by Daniel in 8a2390a4f47
>> >>>
>> >>> Have the defaults for docker engine changed?
>> >>
>> >> No idea as I'm not following their development, but TBH it
>> >> becomes harder and harder to use without tricks (I had to
>> >> add systemd.unified_cgroup_hierarchy=0 to kernel cmdline
>> >> to keep using it).
>> >>
>> >> Maybe I should switch to podman which is the recommended
>> >> engine on Fedora.
>> >>
>> >> Cc'ing Marc-André who added podman support (Daniel is in Cc).
>> > 
>> > I'm using podman exclusively since Docker doesn't work well with
>> > modern distros that use Cgroups v2.
>> 
>> OK this probably explains it.
>> 
>> Ideally we could add a check for this ("modern distro" -> docker
>> engine not recommended) but I guess I'm the only one using this
>> feature on Fedora (as nobody complained) so not a problem. I'll
>> see how to use podman.
>
> I'm not sure we need to block it. If someone has docker installed
> then its reasonable to assume they have ti working. We prefer
> podman if both are installed.

>From my point of view podman is the odd man out (I run upstream
docker.com packages on Debian Buster). I had to jump through some hoops
to get podman installed on my Gentoo box but I think it's currently
broken because it's Gentoo.

IOW I assume the people that really care about podman will shout if it
breaks. It would be nice if we could catch cases in the CI though.

>
>
> Regards,
> Daniel


-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]