fix: glance S3 location churn and undersized memory defaults

[berendt]

Problem

make dizzy-glance against the quick-start ControlPlane kept failing even after #725 bounded the eventlet worker count: 416 of 929 image operations returned HTTP 503, in waves where whole 30-second buckets failed completely. Live diagnosis showed two independent defects:

1. The glance-api container is OOM-killed under load. The bounded two workers are three Python processes carrying boto3/botocore; the container idles near 360Mi of the shared 512Mi limit and overruns it within a minute of concurrent image traffic. Each OOM kill takes the single replica down, and the gateway answers 503 until the crash-loop backoff lets it return.
2. Every image request logs S3 URL mismatch for image ..., updating URL and rewrites the location row. Glance's S3 credential-rotation repair (_construct_s3_url) concatenates the raw s3_store_host — which must keep its http:// prefix for boto3's endpoint_url on non-AWS endpoints like Garage — while the stored location URLs embed only the bare authority (Store._url_prefix strips the prefix). The comparison never converges, so the repair fires on every request, forever.

Fix

Commit 1 introduces the repo's first source patches under patches/glance/{2025.2,2026.1}/: strip the scheme prefix in _construct_s3_url exactly the way Store._url_prefix does. The function is identical in glance 31.1.0 and 32.0.0; both patch files were validated with git apply --check against both upstream tags. It also teaches hack/ci-build-service-image.sh to apply patches after cloning, mirroring .github/actions/checkout-service-source — without this, e2e- and locally-built images would silently diverge from the published GHCR images the moment a patch exists.

Commit 2 gives glance service-specific memory defaults: the defaulting webhook fills an unset spec.deployment.resources with a 512Mi request / 1Gi limit (CPU keeps the shared 100m/500m) before the shared DeploymentSpec defaults run, with the same nil-or-empty guard so explicit values are never clobbered. The shared Resources godoc no longer hardcodes 256Mi/512Mi for every operator; the keystone/horizon/glance CRDs and their Helm chart copies are regenerated, and the concrete values are documented in the per-operator CRD references. Pre-existing CRs keep their materialized resources — the webhook only fills empty blocks.

Verification

Reproduced and verified live on the quick-start stack (kind, Garage S3 backend, dizzy small chaos scenario, 5-minute soak):

	512Mi limit (before)	1Gi limit (after)
Image operations	513/929 OK, 416 × http_503	1034/1034 OK
glance-api restarts during soak	4 (OOMKilled, exit 137)	0
Container memory peak	OOM at 512Mi	576Mi
Throughput	1.7 ops/s	3.4 ops/s

The 576Mi peak sits above the old limit and comfortably below the new one, confirming the old default could not survive the soak regardless of worker count.

Test plan

• go test ./operators/glance/... ./internal/common/... (new webhook unit tests cover the glance-specific defaulting and the explicit-value passthrough)
• make verify-crd-sync, gofumpt -l, shellcheck hack/ci-build-service-image.sh all clean
• Both patch files validated with git apply --check against pristine glance 31.1.0 and 32.0.0 trees (including the SPDX preamble)

🤖 Generated with Claude Code