k8s/bootstrap/phase3-forgejo/forgejo-values.yaml

@@ -97,10 +97,25 @@ gitea:
       # USER and PASSWD injected via env vars below (GITEA__MAILER__USER, GITEA__MAILER__PASSWD)
 
 # Persistence (shared storage for repos)
+#
+# 60Gi, not the original 20Gi. The container registry stores its blobs here,
+# and a single candle-vllm sm_70 image is 14GB uncompressed. At 20Gi the volume
+# filled, and every blob upload failed with:
+#   Package registry API internal error: 500 write /data/tmp/package-upload/...:
+#   no space left on device
+# The push client surfaces that as a bare `received unexpected HTTP status: 500`
+# after retrying every layer, which looks like a network fault and is not one.
+#
+# Note for whoever expands this again: Longhorn's admission webhook checks the
+# PHYSICAL free space of the disk holding each replica, not the thin volume
+# size. A request for 100Gi was rejected while the disk had 23.5Gi free:
+#   disk ... does not have sufficient physical space for expansion:
+#   physical free space would drop below minimal: left=14596177920 < minimal=49931236556
+# 60Gi fit. Raise it in steps and watch the webhook message.
 persistence:
   enabled: true
   storageClass: longhorn
-  size: 20Gi
+  size: 60Gi
   accessModes:
     - ReadWriteOnce
 
@@ -146,19 +161,19 @@ ingress:
 # The database was never the bottleneck. A real action_runner UPDATE measured
 # 2.133ms with zero lock waits, so this is CPU starvation in Gitea itself.
 #
-# requests.cpu rises to 750m because a request below real usage earns the pod
+# requests.cpu stays 200m and limits.cpu stays 1000m. The 3000m limit was a
-# little scheduling weight during contention. limits.cpu rises to 3000m
+# temporary measure while the Actions stall was diagnosed; the real fix landed
-# because diff computation is bursty and needs room to run without throttling.
+# elsewhere, so the limit is back to the original.
 #
-# Caution: this pod runs on talos-cp-3, a control-plane node. 3000m is 25% of
+# Caution: this pod runs on talos-cp-3, a control-plane node. If Gitea
-# that node's 11950m allocatable CPU. If Gitea sustains near this limit, move
+# throttles again at 1000m, move the workload off the control plane rather
-# the workload off the control plane rather than raising the limit again.
+# than raising the limit.
 resources:
   requests:
-    cpu: 750m
+    cpu: 200m
     memory: 768Mi
   limits:
-    cpu: 3000m
+    cpu: 1000m
     memory: 2Gi
 
 # Tolerations for control-plane