Fix the GAIE inferencepool install in the serving stack

[negz]

Fixes #157.
Fixes #158.

The serving stack's Gateway API Inference Extension (GAIE) install, added in #142, can't complete, so a freshly provisioned InferenceCluster never reaches Ready and no model can be scheduled onto it. Three problems, found while bringing up an EKS-backed cluster end to end.

First, the inferencepool chart was pulled from oci://ghcr.io/kubernetes-sigs/gateway-api-inference-extension/charts, which denies anonymous pulls — its token endpoint returns 403. provider-helm can't fetch the chart, so the Release never installs. GAIE publishes the chart for public consumption on registry.k8s.io, which serves it anonymously, so this points the repo there.

Second, with the registry corrected, the install still fails: the inferencepool chart ships no CRDs. It renders a running InferencePool instance plus its endpoint picker and requires inferencePool.modelServers.matchLabels, which the serving stack doesn't set, so the render errors out. The CRDs the serving stack actually wants live in the upstream release's manifests.yaml. This vendors them into the function and applies them as provider-kubernetes Objects on the remote cluster, the same way compose-inference-gateway installs the Gateway API CRDs that the Traefik chart likewise doesn't ship. The upstream manifests are a live-cluster export carrying a top-level status and metadata.creationTimestamp; those are stripped from the vendored copy (with a header note for re-vendoring) so the Object doesn't re-apply every reconcile and trip the composite's watch circuit breaker.

Third, the ai-gateway-crds and ai-gateway releases were composed but never marked ready — they weren't in mark_readiness's list. So even with every release and object healthy on the cluster, the ServingStack's readiness aggregation waited on them forever and the InferenceCluster never reached Ready. This adds them to the list.

The first two unmask each other in sequence (the registry fix reveals the chart-content problem); the third was hidden behind both. Each maps to its own commit.

Validated end to end on an EKS-backed InferenceCluster: with all three fixes the GAIE CRDs install and settle, the serving stack converges, and the InferenceCluster reaches Ready=True.

I have:

• Read and followed Modelplane's contribution process.
• Run nix flake check (or ./nix.sh flake check) and made sure it passes.
• Added or updated tests covering any composition function changes.
• Signed off every commit with git commit -s.

[dennis-upbound]

thanks for doing this. hope this works

[Copilot]

Pull request overview

This PR fixes the ServingStack’s Gateway API Inference Extension (GAIE) installation so newly provisioned InferenceClusters can converge to Ready and schedule models by installing GAIE CRDs directly (instead of via the inferencepool Helm chart) and ensuring AI Gateway releases are included in readiness aggregation.

Changes:

• Vendor GAIE CRDs from the upstream release manifest and compose them as provider-kubernetes Objects on the workload cluster.
• Update serving-stack readiness aggregation to include ai-gateway-crds and ai-gateway.
• Adjust compose-serving-stack unit tests to validate the new GAIE CRD composition shape and readiness behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
functions/compose-serving-stack/function/fn.py	Loads vendored GAIE CRDs, composes them as provider-kubernetes Objects, and marks AI Gateway releases ready in readiness aggregation.
functions/compose-serving-stack/function/gaie_crds.yaml	Adds vendored GAIE CRDs (from upstream manifests.yaml) for installation onto workload clusters.
functions/compose-serving-stack/tests/test_fn.py	Updates tests to expect GAIE CRDs as individual composed Objects and to account for AI Gateway readiness propagation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.