podResourceRequirements applies to every worker pod CDI creates --
importer, uploader and host-assisted cloner alike, not only the importer
the parameter is named for -- so a value set here reaches the console's
disk-upload path as well as the imports. It has to be set on the CDI CR
and not on CDIConfig: the operator reconciles CDIConfig.spec from this
resource, so a direct patch is silently reverted and
status.defaultPodResourceRequirements stays where it was.
The default restates CDI's own built-in values exactly -- limits
750m/600M, requests 100m/60M, read off a live cluster -- so an install
that sets nothing behaves as it did before the parameter existed. That
is deliberate. A 4Gi ceiling was measured as necessary on one hand-built
stand, where the decompress+convert of a tenant worker disk was
OOM-killed at 99.8-100% and CDI then retried from scratch forever, but
the same 20Gi import completes at stock 600M on a QEMU-node cluster and
no CI run on either lane has recorded an OOMKilled importer. What has
been shown to need the headroom is that substrate, so the override lives
with the substrate in hack/e2e-platform-packages.sh rather than here.
The failure being answered is memory, and only memory. CDI already ships
a CPU limit of its own at 750m, nothing measured has asked for more, and
the default here restates that figure rather than raising it.
The package had no `test` target, and hack/helm-unit-tests.sh only runs
a package whose `make -n test` resolves, so a tests/ directory here was
collected by nothing and skipped in silence. Added with the suite.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: LLM
Myasnikov Daniil
0418577f55