## What this PR does
Under node CPU contention the host `linstor-controller` JVM cannot
answer its `GET /health` liveness probe within the piraeus-operator
default timing (`timeoutSeconds: 1`, `failureThreshold: 3`). The kubelet
then liveness-kills the container (exit 137, reason `Error`, not
`OOMKilled`). The resulting crash-loop leaves the `linstor-controller`
Service with no ready endpoints, `linstor-csi` gets `EPERM`, and
RWX-Filesystem `DataVolume`s never bind — breaking tenant Kubernetes /
NFS provisioning.
The operator-generated controller pod sets no `resources` (so no CPU
request and no scheduling/CPU guarantee) and ships the tight default
probe. This change, on the `linstor-controller` container in
`spec.controller.podTemplate`:
- adds `resources.requests` (cpu `250m`, memory `700Mi`) — requests
only, no limits: a CPU request guarantees CPU shares so the JVM keeps
answering `/health` under contention, while omitting limits avoids
throttling the JVM or OOM-killing it. The memory value is a conservative
starting estimate; tune it to observed RSS.
- relaxes the liveness timing to `timeoutSeconds: 5` and
`failureThreshold: 6` so a JVM GC pause or CPU contention does not trip
a liveness kill.
piraeus-operator merges `spec.controller.podTemplate` into the generated
Deployment as a strategic merge patch, so the liveness override carries
only the two timing fields; the operator's `httpGet` target (`GET
/health` on the api port) is left intact to avoid pinning a wrong path
or scheme. Both knobs are exposed under `controller.*` in `values.yaml`
for tuning.
This is a latent chart weakness amplified by load, not a regression: on
the same branch, image, and chart, a green run had the controller stable
at `restartCount=0`, while a CPU-loaded run on identical code
crash-looped. Same code, different outcome under load.
### Screenshots
N/A — no UI changes.
### Release note
```release-note
fix(linstor): give the linstor-controller CPU/memory requests and a more tolerant liveness probe so it no longer crash-loops under node CPU contention, which previously left the controller Service with no endpoints and blocked RWX volume provisioning
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added default controller resource requests for the Linstor controller.
* Added configurable liveness probe timing settings for the controller
container.
* **Tests**
* Added coverage to verify the controller pod template applies the
expected resource requests and liveness probe timing values.
* Confirmed the controller image remains correctly pinned while the new
settings are applied.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
IvanHunters
7801f7748e