Useful to tell whether containers are being made with pasta or
slirp4netns by default. Info is bloated enough already that I
don't really have concerns about shoving more into it.
Fixes#22172
Signed-off-by: Matt Heon <mheon@redhat.com>
Fix following issues:
- create container API handler ignores Annotations from HostConfig
- inspect container API handler does not provide Annotations as
part of HostConfig
Signed-off-by: diplane <diplane3d@gmail.com>
New run_minikube() helper, modeled after run_podman(). Echoes
each command being run and its output. On failure, runs minikube logs.
Addresses (does not close) #21931 which is hitting us hard in CI.
Probably quay flakes, but it's impossible to tell without logs.
Also: bug fix: one "run podman" fixed to run_podman
Signed-off-by: Ed Santiago <santiago@redhat.com>
By default we just ignored any localhost reolvers, this is problematic
for anyone with more complicated dns setups, i.e. split dns with
systemd-reolved. To address this we now make use of the build in dns
proxy in pasta. As such we need to set the default nameserver ip now.
A second change is the option to exclude certain ips when generating the
host.containers.internal ip. With that we no longer set it to the same
ip as is used in the netns. The fix is not perfect as it could mean on a
system with a single ip we no longer add the entry, however given the
previous entry was incorrect anyway this seems like the better behavior.
Fixes#22044
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In some environments, such as the one described in
https://github.com/containers/podman/issues/20927, the default route
is given as nexthop gateways. That is, it's a multipath routes with
multiple gateways.
That means that pasta(1), after commit 6c7623d07bbd ("netlink: Add
support to fetch default gateway from multipath routes"), can start
and use a default gateway from that route.
Just like in pasta(1), in these tests, the default route indicates
which upstream interface we should pick. If we ignore multipath
routes, IPv6 addresses and gateway addresses themselves won't be
available, so, while pasta is now able to configure the container,
IPv6 tests will expect to find no address and no gateway, hence fail
due to the mismatch.
Try to get routes, including gateway addresses and interface names,
from nexthop objects, in case the selection of a regular default
route yields no results.
Link: https://github.com/containers/podman/issues/20927Closes: #20927
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
The annotations should be maintained by CRI-O itself to decouple the
projects from a dependency perspective.
[NO NEW TESTS NEEDED]
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Most of them look like our usual "assume too much about run -d".
One of them is just an unexpected warning, a push retry. Remove
the ExitCleanly() from that test, just rely on Exit(0).
The other two have to do with podman logs, which we know can lag.
Add a short 1-second retry loop.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Two test flakes in the past week. Looks like the usual race
between "run -d" and "assume the container is ready". I don't
know if this will resolve them, but it's still a good idea.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Commit 03f6589f3 added basic support for pull-error event from libimage
but it contains several problems:
1. storing the error as error type prevents it from being unmarshalled,
thus change it to a string
2. the error was never propagated from the libimage event to the podman
event struct
3. the error message was not wired into the cli and API
This commit fixes these problems.
Fixes#21458
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There are many code paths which only do logrus but still exit 0 so this
should catch more bugs. Unfortunately runc logs way to much random stuff
so we ignore this check for runc right now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
when performing a system reset with containers that run somewhere where
a soft kill wont work (like sleep), containers will wait 10 seconds
before terminating with a sigkill. But for a forceful action like
system reset, we should outright set no timeout so containers stop
quickly and are not waiting on a timeout
Fixes#21874
Signed-off-by: Brent Baude <bbaude@redhat.com>
This vendors the latest c/common version, including making Pasta
the default rootless network provider. That broke a number of
tests, which have been fixed as part of this PR.
Also includes a change to network stats logic, which simplifies
the code a bit and makes it actually work with Pasta.
Signed-off-by: Matt Heon <mheon@redhat.com>
fix an assumption in the test, that the --compression-format is
unchanged from the original image.
Instead validate that all the required architectures are part of the
manifest.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Add a --artifact flag to `podman manifest add` which can be used to
create an artifact manifest for one or more files and attach it to a
manifest list. Corresponding --artifact-type, --artifact-config-type,
--artifact-config, --artifact-layer-type, --artifact-subject, and
--artifact-exclude-titles options can be used to fine-tune the fields in
the artifact manifest that don't refer to the files themselves.
Add a --index option to `podman manifest annotate` that will cause
values passed to the --annotation flag to be applied to the manifest
list as a whole instead of to an entry in the list.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Checking for the mountdir is not relevent, a recent c/storage change[1] no
longer deletes the mount point directory so the check will cause a false
positive. findmnt exits 1 when the given path is not a mountpoint so
let's use that to check.
[1] 3f2e81abb3
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Upgrade-from-v4.1 was temporarily disabled in #21618: we brought
in new CI VMs, and v4.1 setup no longer works. Nobody quite
understands why, and we've hit diminishing returns in the
investigation (#21863). The current thinking is that it
is related to netavark, and versions < 1.3 do not work
in the current f39 VMs. (No clue why, because f39 kernel
did not change in #21618).
Anyhow, reenable the pre-4.8 upgrade test, using v4.3.1
which has netavark-1.4.0 which seems to work fine. For now.
Also, some upgrade test cleanup:
- Skip, not fail, if initial setup fails. Makes for less noisy logs.
- Remove duplicate --pid=host
- Ports: 808x -> 909x, because 8081 is used by restraint on 1mt
Signed-off-by: Ed Santiago <santiago@redhat.com>
Like docker podman network inspect should output the information of
running container with their ip/mac address on this network.
However the output format is not docker compatible as this cannot
include all the info we have and the previous output was already not
compatible so this is not new.
New example output:
```
[
{
...
"containers": {
"7c0d295779cee4a6db7adc07a99e635909413a390eeab9f951edbc4aac406bf1": {
"name": "c2",
"interfaces": {
"eth0": {
"subnets": [
{
"ipnet": "10.89.0.4/24",
"gateway": "10.89.0.1"
},
{
"ipnet": "fda3:b4da:da1e:7e9d::4/64",
"gateway": "fda3:b4da:da1e:7e9d::1"
}
],
"mac_address": "1a:bd:ca:ea:4b:3a"
}
}
},
"b17c6651ae6d9cc7d5825968e01d6b1e67f44460bb0c140bcc32bd9d436ac11d": {
"name": "c1",
"interfaces": {
"eth0": {
"subnets": [
{
"ipnet": "10.89.0.3/24",
"gateway": "10.89.0.1"
},
{
"ipnet": "fda3:b4da:da1e:7e9d::3/64",
"gateway": "fda3:b4da:da1e:7e9d::1"
}
],
"mac_address": "f6:50:e6:22:d9:55"
}
}
}
}
}
]
```
Fixes#14126
Fixes https://issues.redhat.com/browse/RHEL-3153
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I'm tired of this flake, it's hitting us ~once/day. Root cause
still unknown.
Workaround: add a READY file to the http server, and run 'curl'
until we get it. Tested in #17831 for the last two weeks, flake
has not been seen even once since then.
Closes: #21649
Signed-off-by: Ed Santiago <santiago@redhat.com>
