---
id: RAIL-KNATIVE-WP-0002
type: workplan
title: "Declare the Knative substrate CPU requests set live on railiance01"
domain: financials
repo: rail-knative
status: active
owner: codex
topic_slug: railiance
created: "2026-09-21"
updated: "2026-09-21"
depends_on: []
---

# RAIL-KNATIVE-WP-0002 - Declare the Knative substrate CPU requests

On 2026-09-21 the CPU requests of the Serving and Kourier v1.22.0 install on
railiance01 were lowered live (`ADMINISTER @ realm:kubernetes/railiance01`,
activation=APPROVED by the founder). Limits are unchanged. Record:
`the-custodian/docs/kubernetes-change-gate-decision.md`. Runbook:
`docs/substrate-runbook.md`.

## T01 - Declare the requests over the pinned v1.22.0 assets

```task
id: RAIL-KNATIVE-WP-0002-T01
status: done
priority: high
```

2026-09-21: Added `substrate/v1.22.0/cpu-requests.patch.yaml` and a
kustomization over the staged `core.yaml` and `kourier.yaml`, with offline
tests. Rendered against the checksum-verified upstream assets (hashes from
`railiance-cluster/install/knative/release-lock.env`): the six Deployments
carry exactly the declared CPU requests, with upstream memory and limits.

## T02 - Verify the declaration against live, read-only

```task
id: RAIL-KNATIVE-WP-0002-T02
status: done
priority: high
```

2026-09-21: `kubectl get deploy -o jsonpath` over `ssh railiance01` read
activator 50m, autoscaler 30m, controller 30m, webhook 30m,
net-kourier-controller 30m, 3scale-kourier-gateway 50m; limits 1 (webhook
500m), matching upstream. The namespace version label is 1.22.0. HPAs:
activator 2%/100%, webhook 10%/100%, gateway 10%/100%. Declared equals live.

## T03 - Make the railiance-cluster installer apply the declaration

```task
id: RAIL-KNATIVE-WP-0002-T03
status: wait
priority: high
```

Waits on railiance-cluster, which owns the install (`install/knative/`).
rail-knative does not edit that repository. The installer must apply
`substrate/v1.22.0/cpu-requests.patch.yaml` after each upstream apply, for
example by building the kustomization over its staged files, or by running
`kubectl patch deployment <name> -n <ns> --type strategic --patch-file <doc>`
per document; `verify.sh` should assert the six requests.

Because the values are already live, re-running the patched installer changes
no running state. Running the *unpatched* installer before this lands reverts
the requests and should not be done. Rollback of the installer change is a
revert of its commit; the live values need no rollback.