The network functions popped up in the CPU profiles when listing 2042
containers. Not a very realistic or common use case but a nice way to
get something on the CPU profiles.
Listing 2042 containers now runs 1.54 times faster.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Small amount of refactoring to make WSL specific stuff into the WSL
package where possible. This is in preparation for the possibility of
adding more virtualization backends.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Add a set of scripts using hyperfine for comparing two container
engines. I am currently using the scripts for comparing Podman
and Docker, and with older versions of Podman.
These scripts are not meant for production usage but to aid in tracking
down performance regressions and bottlenecks.
Run the scripts via `sudo sh $script.sh`.
Use the following environment variables to change the default behavior:
* `ENGINE_A` to set container engine A (default `/usr/bin/podman`)
* `ENGINE_B` to set container engine B (default `/usr/bin/docker`)
* `RUNS` to change the runs/repetitions of each benchmarks (default `100`)
* `NUM_CONTAINERS` to change the number of created containers for some benchmarks (e.g., `ps`) (default `100`)
* `IMAGE` to change the default container image (default `docker.io/library/alpine:latest`)
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The user is only reading the config, so creating a copy turns out to be
extremely expensive. With this change, listing containers is 1.39 times
faster than before.
[NO NEW TESTS NEEDED] as it is not a functional change.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
After https://github.com/containers/netavark/pull/452 `netavark` is
incharge of deciding `custom_dns_servers` if any so lets honor that and
libpod should not set these manually.
This also ensures docker parity
Podman populates container's `/etc/resolv.conf` with custom DNS servers ( specified via `--dns` or `dns_server` in containers.conf )
even when container is connected to a network where `dns_enabled` is `true`.
Current behavior does not matches with docker, hence following commit ensures that podman only populates custom DNS server when container is not connected to any network where DNS is enabled and for the cases where `dns_enabled` is `true`
the resolution for custom DNS server will happen via ( `aardvark-dns` or `dnsname` ).
Reference: https://docs.docker.com/config/containers/container-networking/#dns-services
Closes: containers#16172
Signed-off-by: Aditya R <arajan@redhat.com>
Aardvark-dns and netavark now accepts custom DNS servers for containers
via new config field `dns_servers`. New field allows containers to use
custom resolvers instead of host's default resolvers.
Following commit instruments libpod to pass these custom DNS servers set
via `--dns` or central config to the network stack.
Depends-on:
* Common: containers/common#1189
* Netavark: containers/netavark#452
* Aardvark-dns: containers/aardvark-dns#240
Signed-off-by: Aditya R <arajan@redhat.com>
mount_program is in storage.options.overlay and not storage.options
(see example in storage.conf)
Signed-off-by: Klaus Frank <agowa338@users.noreply.github.com>
`default` is already used as network mode, i.e. podman run --network
default will choose the default mode not a network named `default`.
We already block names from other network modes, default was forgotten.
Fixes#17169
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is only needed for one CI task, and that task already calls
`make .install.swagger` in setup_environment.sh.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Where the terms CNI and cni are used in documentation like man pages,
readme's, and tutorials, we have begun to add deprecation notices where
applicable. In cases where netavark cannot do what CNI can, those have
been left alone.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Output from podman system service, on system tests, is
being saved... it just hasn't been collected as an artifact.
Start collecting it. And, remove obsolete-unused-misleading
code that made me think it _was_ being collected.
Also: log system-service output for bud tests, and set
log-level to info per suggestion from @Luap99
Signed-off-by: Ed Santiago <santiago@redhat.com>
Kill is a fast syscall, so we can reduce the sleep time from 100ms to
10ms in hope to speed things up a bit.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Commit 067442b570 improved stopping/killing a container by detecting
whether the cleanup process has already fired and changed the state of
the container. Further improve on that by returning early instead of
trying to wait for the PID to finish. At that point we know that the
container has exited but the previous PID may have been recycled
already by the kernel.
[NO NEW TESTS NEEDED] - the absence of the two flaking tests recorded
in #17142 will tell.
Fixes: #17142
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add a comment when SIGKILL is being used. It may help future readers
better comprehend what's going on and why.
[NO NEW TESTS NEEDED] - cannot test a comment :^)
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Move the stopSignal decl into the branch where it's actually used.
[NO NEW TESTS NEEDED] as it's just a small refactor.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The code can be simplified by using a timer directly.
[NO NEW TESTS NEEDED] - should not change behavior.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
July 2022: test was flaking on new VM images. We needed new
images, so I filed #15014 and skipped the test.
January 2023: no attention from anyone, so I'll try bumping up
a dd timeout from 10s to 30s. But in the interim, the test
has broken: it used to expect "Containerfile" in output (this
was deliberately added in #13655)... but #16810 changed that
so Containerfile no longer appears. @flouthoc argues that
this too is deliberate (#17059). Okay, so let's change the
test then. All I care about is not adding more regressions.
Signed-off-by: Ed Santiago <santiago@redhat.com>
