As this function is only used by runtimeVM::ContainerStats(), let's move
it to the runtime_vm.go file, making our life easier when doing upcoming
changes on runtimeVM::ContainerStats().

Signed-off-by: Fabiano Fidêncio <[email protected]>

CRI-O has been using `containers/libpod/pkg/cgroups` in order to get
metrics and, later on, convert it to CRI Stats. Although this approach
is fine (and desired) for the OCI runtime type. we can't rely on that
for the VM runtime type as the data sent by Kata Containers comes from
`containerd/cgroup`.

Signed-off-by: Fabiano Fidêncio <[email protected]>

WorkingSetBytes is the bit that needs to be set in order to provide
kubelet the pod's memory information.

Although it's calculated in a slightly different way for "oci" runtime
type, the logic is quite similar for the "vm" runtime type, with the
only difference being where the TotalInactiveFile information comes
from.

This is the last bit needed in order to have `kubectl top pod $pod`
working, as shown below:
```
[fidencio@localhost cri-o]$ kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
example-fedora   1/1     Running   0          130m

[fidencio@localhost cri-o]$ kubectl get pod example-fedora -o yaml | grep runtimeClassName
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"app":"example-fedora-app"},"name":"example-fedora","namespace":"default"},"spec":{"containers":[{"args":["-m","http.server","8080"],"command":["python3"],"image":"fedora:33","name":"example-fedora","ports":[{"containerPort":8080}]}],"runtimeClassName":"kata"}}
        f:runtimeClassName: {}
  runtimeClassName: kata

[fidencio@localhost cri-o]$ kubectl top pod
NAME             CPU(cores)   MEMORY(bytes)
example-fedora   1m           9Mi
```

Signed-off-by: Fabiano Fidêncio <[email protected]>

Fix Bug 1942608, during the call of ListImages, do not list the image if the there's no manifest exist.
Skip reporting the error locating manifest if the imaage is in the ImageBeingPulled list.

Signed-off-by: Qi Wang <[email protected]>

…pick-4470-to-release-1.21

[release-1.21] Properly implement metrics for Kata Containers when using CRI stats.

…pick-4726-to-release-1.21

[release-1.21] Bug 1942608: do not list the image with error locating manifest

Signed-off-by: Peter Hunt <[email protected]>

If we fail to initially attach the namespaces, we need to cleanup the ones we've already created
Also, we are currently unconditionally recreating the namespaces when restoring. I believe that's from a rebase issue

Signed-off-by: Peter Hunt <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

[1.21] bump to containers/image 5.11.1

…pick-4758-to-release-1.21

[release-1.21] nsmgr: fix some leaks with GetNamespace

Signed-off-by: Peter Hunt <[email protected]>

…pick-4796-to-release-1.21

[release-1.21] container server: fix silly typo

This is a partial revert of 975ffc6,
where we started using the internal log when the context is avaiable.

It turns out that we missed a few pieces during the review, where we end
up using the internal log without having the interceptors set up.  This
was raised by @haircommander during the review, we checked a few parts
of the patch, but we still missed a few others.

We can only use the internal logging after
https://github.com/cri-o/cri-o/blob/d3dbaec060e33870e5cb5c3f7ec4207837804b00/cmd/crio/main.go#L222
happens.  From this moment, we start having different ways of logging in
the very same file and consistency becomes a problem then.

With the consistency in mind, I'd like to **only** use logrus for
debugging as part of this file.

Note: This was noticed when debugging
cri-o#4798

Signed-off-by: Fabiano Fidêncio <[email protected]>

as well as mark the feature as experimental

Signed-off-by: Peter Hunt <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

…pick-4787-to-release-1.21

[release-1.21] workloads: update how overrides are specified

We now partially revert cri-o#4650 to
still use the runtime internal context for its tasks.

Fixes: cri-o#4798

Signed-off-by: Sascha Grunert <[email protected]>

…pick-4803-to-release-1.21

[release-1.21] Use extra context for runtime VM

…pick-4804-to-release-1.21

[release-1.21] main: still rely on logrus (rather than using the internal log)

This allows us to predictably shut down the node and help ensure
clean shutdown.

Signed-off-by: Mrunal Patel <[email protected]>

The internal seccomp profile (`RuntimeDefault`) should be ignored in the
same way as it was before using the new field. This aligns the
implementation with CRI-O releases before v1.21.0.

Signed-off-by: Sascha Grunert <[email protected]>

Signed-off-by: Mrunal Patel <[email protected]>

…pick-4789-to-release-1.21

[release-1.21] Fix RuntimeDefault seccomp behavior if disabled

…pick-4766-to-release-1.21

[release-1.21] Add After=crio.service dependency to containers and conmon

[1.21] Fix podman name in README

Signed-off-by: Peter Hunt <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

…pick-4828-to-release-1.21

[release-1.21] Pin gocapability to v0.0.0-20180916011248-d98352740cb2

Signed-off-by: Peter Hunt <[email protected]>

[1.21] bump runc to 1.0.0-rc94

Signed-off-by: Peter Hunt <[email protected]>

…1.21

[1.21] bump c/storage to 1.31.1

Signed-off-by: Sascha Grunert <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

[1.21] bump to v1.21.1

[1.21] Fix CI

Signed-off-by: Peter Hunt <[email protected]>

…pick-4966-to-release-1.21

[release-1.21] storage: succeed in DeleteContainer if container is unknown

there's a line in the kubelet leaky file that says it should be deleted
we need an importable InfraName anyway, so move all references from leaky.PodContainerName or infraName
to server/cri/types.InfraName

Signed-off-by: Peter Hunt <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

currently, workloads are only configured for the containers in the pod.
This is insufficient for clients that want to keep a whole pod confined in a workload.

Add functionality where conmon will also be put into the workload

Signed-off-by: Peter Hunt <[email protected]>

Signed-off-by: Peter Hunt <[email protected]>

…CPUs

Signed-off-by: Peter Hunt <[email protected]>