Don't use the fixed path to allow searching in system local paths.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>

…8708-to-release-1.31

[release-1.31] nix: don't build gpgme with `--enable-fixed-path`

This allows defining a RuntimeHandler with custom
annotations or other fields while inheriting the
runtime type from the default runtime.

This behavior is useful for layered projects
that are not in control of the runtime selection
but need to tweak the specific behavior while
inheriting the node global runtime.

Signed-off-by: Martin Sivak <msivak@redhat.com>

…8754-to-release-1.31

[release-1.31] RuntimeHandler inheritance

The original PR missed few important bits

- the reload code path was not the only one that loads configs
- an empty RuntimePath has a special meaning and inheriting it
  does not inherit the parent runtime
- golang does a copy during interation, not a reference and the
  updated values were forgotten
- the unit test ignores some of the checks during CI when not
  on a bare metal

This patch fixes all of these and adds better logging
and also tests that actually catch the above mistakes.

Signed-off-by: Martin Sivak <msivak@redhat.com>

…8768-to-release-1.31

[release-1.31] RuntimeHandler inheritance bug-fix

Add the option to be able to fine-tune the pull progress timeout or even
disable it.

Fixes #8764 and #8760

Follow-up on: #7887

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>

…8765-to-release-1.31

[release-1.31] Add `--pull-progress-timeout` / `pull_progress_timeout` option

To avoid the situation where a container that is restored via a registry
mounts unexpected host paths into the container, this changes the
restore behaviour of CRI-O.

Previously all bind mounted paths in the original container which were
defined for example like this:

    volumeMounts:
    - mountPath: /data
      name: data-volume
  volumes:
  - name: data-volume
    hostPath:
      path: /srv/container/data

Were automatically mounted in the restored container without and
definition necessary. This lead to the situation that the user does not
know which path will be mounted if starting a restored container.

Now CRI-O will refuse to restore a container if not all bind mounts are
defined via the CRI CreateContainer RPC in the CreateContainerRequest
message.

CRI-O will now return an error that will look something likes this:

Error: the container to restore (7f...be) expects following bind mounts defined (/data,/data2)

Now the user has to explicitly add those bind mounts in the same way as
it was done during initial container creation.

Signed-off-by: Adrian Reber <areber@redhat.com>

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>

…ef7c36-to-release-1.31

[release-1.31] Only restore container if all bind mounts are defined

Signed-off-by: Kubernetes Release Robot <k8s-release-robot@users.noreply.github.com>

Bump version to 1.31.3