11 Commits

Author SHA1 Message Date
42e8322532 vendor containers projects to tagged versions
Updates:
 - c/storage v1.56.0
 - c/image v5.33.0
 - c/common v0.61.0
 - c/buildah v1.38.0
 - c/libhvee v0.9.0
 - github.com/crc-org/crc/v2 v2.43.0

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2024-11-12 10:51:22 +01:00
2f858675b3 vendor latest c/common
Includes my pasta changes.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2024-09-06 14:42:56 +02:00
75a316aae4 vendor: bump c/common
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2024-07-31 21:55:28 +02:00
b234bb55e4 Bump Buildah to v1.35.0
As the title says.  This is the last step in the vendor dance for
Podman v5.0.

[NO NEW TESTS NEEDED]

Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
2024-03-07 11:51:09 -05:00
7c8c945496 Vendor in latest c/common
Pull in updates made to the filters code for
images. Filters now perform an AND operation
except for th reference filter which does an
OR operation for positive case but an AND operation
for negative cases.

Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
2024-01-25 11:10:41 -05:00
75b4679a73 vendor of containers/(common, storage, image)
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2023-09-11 13:52:23 -04:00
34235b2726 system df: fix image-size calculations
Fix two bugs in `system df`:

1.  The total size was calculated incorrectly as it was creating the sum
    of all image sizes but did not consider that a) the same image may
    be listed more than once (i.e., for each repo-tag pair), and that
    b) images share layers.

    The total size is now calculated directly in `libimage` by taking
    multi-layer use into account.

2.  The reclaimable size was calculated incorrectly.  This number
    indicates which data we can actually remove which means the total
    size minus what containers use (i.e., the "unique" size of the image
    in use by containers).

NOTE: The c/storage version is pinned back to the previous commit as it
      is buggy.  c/common already requires the buggy version, so use a
      `replace` to force/pin.

Fixes: #16135
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
2022-10-19 11:20:41 +02:00
fdba0d7909 Vendor in latests containers/storage and opencontainers/runtime-tools
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2022-07-18 13:25:01 -04:00
f67ab1eb20 Vendor in containers/(storage,image, common, buildah)
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2022-07-18 10:42:04 -04:00
b92149e2a8 podman pod create --memory
using the new resource backend, implement podman pod create --memory which enables
users to modify memory.max inside of the parent cgroup (the pod), implicitly impacting all
children unless overriden

Signed-off-by: Charlie Doern <cdoern@redhat.com>
2022-07-01 13:44:32 -04:00
2792e598c7 podman cgroup enhancement
currently, setting any sort of resource limit in a pod does nothing. With the newly refactored creation process in c/common, podman ca now set resources at a pod level
meaning that resource related flags can now be exposed to podman pod create.

cgroupfs and systemd are both supported with varying completion. cgroupfs is a much simpler process and one that is virtually complete for all resource types, the flags now just need to be added. systemd on the other hand
has to be handeled via the dbus api meaning that the limits need to be passed as recognized properties to systemd. The properties added so far are the ones that podman pod create supports as well as `cpuset-mems` as this will
be the next flag I work on.

Signed-off-by: Charlie Doern <cdoern@redhat.com>
2022-06-24 15:39:15 -04:00