catalog: two tiny services, so the loop can be exercised on a full cluster

The three existing entries are sized like real products: `elasticsearch` small asks for 1Gi and medium for 4Gi across three replicas. On this cluster that is a request that never schedules, so provisioning them proves something about the node and nothing about svcforge. podinfo 16Mi/10m — one small Go binary, no dependencies, no PVC nginx 32Mi/10m — recognisable, still small Both are addressed as `oci://`, which is load-bearing rather than cosmetic. An OCI chart is pulled by reference with no `helm repo add` first. The three existing entries name `bitnamilegacy/<chart>`, a classic repo alias that nothing in the worker image configures — so as written they cannot resolve at provision time. OCI is the form that works from a bare container, and it is why the e2e test already provisions podinfo. Chart versions were resolved against the real registries before committing (podinfo 6.7.1, nginx 25.0.14 / app 1.31.3) rather than guessed, since a wrong version fails only at provision time. Also updates the CLI ServiceType enum, the catalog test's expected set, and the service list in the OpenAPI description.
2026-07-21 05:47:41 +00:00
parent bb8b14ef03
commit 6974b3620f
5 changed files with 76 additions and 3 deletions
@@ -91,7 +91,9 @@ async def lifespan(app: FastAPI) -> AsyncIterator[None]:
 # to create_app rather than in a README because /docs is what someone integrating actually
 # reads, and a README in this repo is not something they have.
 API_DESCRIPTION = """
-Provision managed service instances (Elasticsearch, Redis, Postgres) into Kubernetes.
+Provision managed service instances into Kubernetes. The catalog offers Elasticsearch,
+Redis and Postgres, plus two deliberately tiny entries — `podinfo` and `nginx` — for
+exercising the platform where there is no room for the real thing.

 ## Authentication