Loading container states speed things up when listing all containers but
it comes with a price tag for many other call paths. Hence, make
loading the state conditional to allow for keeping `podman ps` fast
without other commands regressing in performance.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Do not sync containers with the runtime and the database when listing
containers. It turns out to be extremely expensive and unnecessary.
The sync was needed since listing all containers from the database did
not populate their state. Doing that, however, is much faster since we
already have a connection to the database.
This change makes listing 200 containers 2 times faster than before.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The test was added in commit 1424f0958f, it can flake because the
attach test needs the message in the log. On slow CI systems this can
take longer. Add a retry logic which checks the container log every
second for up to 5 seconds. That should be plenty of time.
Fixes#17204
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If the image being used has a user set that is a positive
integer greater than 0, then set the securityContext.runAsNonRoot
to true for the container in the generated kube yaml.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Also do not return (and immediately suppress) an error if no health
check is defined for a given container.
Makes listing 100 containers around 10 percent faster.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
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>
Valentin Rothberg