Lower Repo Radius ephemeral control-plane PostgreSQL CPU request

[pujitha24]

Summary

Lower the PostgreSQL scheduling CPU request for the ephemeral "Repo Radius"
control-plane install in setup-control-plane from the chart default (2
cores) to 250m. The CPU limit is left untouched at the chart default (2
cores), so PostgreSQL can still burst to full CPU once scheduled.

Reason for change

GitHub-hosted standard runners (ubuntu-24.04) give private/internal
repositories 2 vCPU, versus 4 vCPU for public repositories on the same
runner label. The Radius chart's default database.resources.requests.cpu
is "2" (2 full cores). Combined with the BuildKit sidecar's 200m request
and k3s's built-in CoreDNS (100m) and metrics-server (100m) requests,
the ephemeral k3d control-plane node cannot schedule all control-plane pods
on a 2-vCPU private-repo runner: PostgreSQL stays Pending, UCP (which
depends on it) never becomes Available, and rad install kubernetes
times out waiting for the control plane.

This only changes the ephemeral, low-traffic control-plane install used by
the reusable "Repo Radius" workflow (setup-control-plane is the shared
composite action invoked by run-rad-commands-azure.yml,
run-rad-commands-aws.yml, delete-azure.yml, and delete-aws.yml). It
does not touch deploy/Chart/values.yaml, so the chart's default for
production installs is unaffected.

Fixes #

How to test

From the repo root:

# Confirms the override actually reaches the rendered StatefulSet, and that
# only the request (not the limit) changes:
helm template radius deploy/Chart \
  --set database.enabled=true \
  --set database.resources.requests.cpu=250m \
  -s templates/database/statefulset.yaml

# Repo's own Helm lint/unit tests and composite-action shell-syntax check:
helm lint deploy/Chart
make test-helm
make test-extension-action-shell-syntax

All four passed. helm template showed the database container's
resources.requests.cpu drop from the chart default "2" to "250m",
while resources.limits.cpu stayed at "2". helm lint passed with 0
failures. make test-helm (helm-unittest) passed 131/131 existing chart
tests, confirming no regression (this change does not touch chart
templates or values). make test-extension-action-shell-syntax validated
18 run: blocks across 10 composite action.yml files, including the
edited one, with no syntax errors.

Disclosure: this sandbox has no Docker/k3d available, so a live 2-vCPU-
constrained k3d cluster reproduction (PostgreSQL Pending before, Running
after) was not possible here. With the fix, the ephemeral node's CPU
scheduling requests total 250m (database) + 200m (buildkit) + 100m
(CoreDNS) + 100m (metrics-server) = 650m, well under a 2-vCPU (2000m)
runner's capacity, versus 2050m+ before the fix, which already exceeds
2000m before the other pods are even considered — matching the issue's own
reported math. Recommend confirming with one real run of the reusable
workflow on a private-repo 2-vCPU runner post-merge.

File change summary

File	Summary of change
.github/extension/actions/setup-control-plane/action.yml	Add --set database.resources.requests.cpu=250m to the rad install kubernetes call so the ephemeral control-plane's PostgreSQL requests less CPU than the chart default, fixing scheduling on 2-vCPU private-repo runners; limit is left at the chart default.

Fixes #12857

[Copilot]

Pull request overview

This PR adjusts the reusable “Repo Radius” ephemeral control-plane install to reduce PostgreSQL’s CPU scheduling request so the control plane can successfully schedule on 2‑vCPU GitHub-hosted runners used by private/internal repositories, without changing production chart defaults.

Changes:

• Add a Helm override to set database.resources.requests.cpu=250m during rad install kubernetes in the setup-control-plane composite action.
• Document the rationale inline, clarifying that only the request is lowered while the chart default limit remains unchanged.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[pujitha24]

Heads up: .github/extension/ (including the setup-control-plane action this PR edits) was deleted from this repo in #12719 and now lives solely in radius-project/ai-extensions, so this branch currently conflicts with main. I checked the current copy there and it still calls rad install kubernetes --set database.enabled=true ... without a CPU request override, so the 2-vCPU scheduling issue from #12857 looks unfixed in its new home.

I don't want to guess at whether you'd rather close this in favor of a port to ai-extensions or handle it some other way, so I'll leave that call to you — happy to open the equivalent fix over there if that's the preferred path.

[willdavsmith]

Thanks for the contribution @pujitha24 !

I believe we moved these workflows here: https://github.com/radius-project/ai-extensions/

would you be able to re-create the PR in that repo?