Until widely used and pre-installed in the VM image, simply pull the
latest build from the upstream netavark CI system.
Signed-off-by: Chris Evich <cevich@redhat.com>
After containers/podman/issues/10682, we decided to always re-pull
images of non-local platforms and match *any* local image. Over time, we
refined this logic to not *always* pull the image but only if there is a
*newer* one. This has slightly changed the semantics and requires to
perform platform checks when looking up a local image. Otherwise, bogus
values would match a local image and mistakenly return it.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
If the dhcp ipam driver is used podman does not know any subnets so we
cannot verify if the given static ip is in the subnet.
Fixescontainers/podman#12762
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When pulling down an image with a user-specified custom platform, we
try to make sure that user gets what they are asking for. An inherent
issue with multi-arch images is that there are many images in the wild
which do not get the platform right (see containers/podman/issues/10682).
That means we need to pessimistically assume that the local image is
wrong and pull the "correct" one down from the registry; in the worst case
that is redundant work but we have a guarantee of correctness.
Motivated by containers/podman/issues/12707 I had another look at the
code and found some space for optimizations. Previously, we enforced
the pull policy to "always" but that may be too aggressive since we may
be running in an airgapped environment and the local image is correct.
With this change, we enforce the pull policy to "newer" which makes
errors non-fatal in case a local image has been found; this seems like a
good middleground between making sure we are serving the "correct" image
and user friendliness.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Podman CI wants that for pruning. The pruning code unconditionally sets
the dangling filter since that's crucial for pruning.
Also fix a typo in the error message:
`s/more then/more than/`
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Path-based transports may contain characters that are invalid for a
reference. In such cases, we should pessimistically generate an ID
and not attempt to look at the (possibly path-based) string within the
transport.
This fixes an error when running `podman run dir:/tmp/CapitalChar` and
will prevent the same issue for the upcoming SIF transport.
Extend the tests to make sure we're not going to regress in the future.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When looking up an image by digest, make sure that the matching image is
also subject to further attribute checks (e.g., manifest list checks) as
specified by the user.
Fixes: containers/podman/issues/12729
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
It is possible that two processes write at the same time and this could
lead to an invalid value in the file.
I think this fixes a race condition which was observed in the buildah
integration tests.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
While we can store the default network name outside this network
interface it can become out of sync with the interface.
In buildah it can be useful to get the name from the interface.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The HardwareAddr type must bbe the actual value and not a pointer
otherwise the marshal logic will not use this function. Added a test to
confirm that this works.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We should not use XDG_RUNTIME_DIR for the ipam db. This directory is
shared but we need the ipam db per storage. We can use the runroot for
this. It should be a tmpfs to reset the ipam assignments after a reboot.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If the caller can decide the lockfile path it is just more likely that
there is a lock missmatch due different lock names. We should always
just use the config dir and use a lock with a static name.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When the network backend is unset in the config we have to to figure out
if we need CNI or netavark. New installs should use netavark while
existing installs should continue to use CNI to prevent breaking
systems.
We use the following conditions to determine what backend to use:
1. read ${graphroot}/defaultNetworkBackend
2. find netavark binary (if not installed use CNI)
3. check containers, images and CNI networks and if there are some
we have an existing install and should continue to use CNI
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Buildah, containers and probably other container engines are normalizing
the platform parameters to support common values. For instance, "x86_64"
is normalized to the OCI conformant "amd64".
Use the same normalization when copying images and looking up local
images. Also add some debug logs to facilitate future debugging.
Fixes: containers/podman/issues/12680
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
add the same check we already have for other controllers, since
`createCgroupDirectory` is meant to be used on cgroup v1 only.
Closes: https://github.com/containers/common/issues/862
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Path-based transports may contain characters that are invalid for a
reference. In such cases, we should pessimistically generate an ID
and not attempt to look at the (possibly path-based) string within the
transport.
This fixes an error when running `podman run dir:/tmp/CapitalChar` and
will prevent the same issue for the upcoming SIF transport.
Extend the tests to make sure we're not going to regress in the future.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
OpenShift Merge Robot
Daniel J Walsh
Chris Evich
dependabot[bot]
Paul Holzinger
Valentin Rothberg
ye.sijun
ttyS3
Giuseppe Scrivano
flouthoc