What problem are you facing?
InferenceCluster provisions clusters on two clouds today: GKE via compose-gke-cluster and EKS via compose-eks-cluster, each a Python composition function behind an internal GKECluster / EKSCluster XR. The Ecosystem backlog has around twenty more clouds queued (#290–#305, #93, #94), with Nebius (#299) next.
Each new cloud is another cluster composition function. I want to make sure our implementations don't drift as we add more. I imagine we'll lean heavily on agents to do this work.
I'm worried about two kinds of drift:
- Behavioral: an implementation tracks readiness, gates a dependent resource, or hands off its kubeconfig a little differently, passes review because it looks plausible, and now one cloud carries a bug the others don't.
- Stylistic: I don't want to implement the same thing N different ways. Our patterns, naming, etc should be clear and consistent so that if you've worked on one implementation you don't need to learn new patterns to work on another.
How could Modelplane help solve your problem?
I'm not sure. Some options:
- A written contract and reference: what every implementation must expose (the API shape) and deliver (kubeconfig Secret, cache StorageClass), plus the conventions, with GKE and EKS as the worked examples.
- A skill carrying that same content as an agent workflow, given how agentic this work will be.
- Conformance tests each implementation must pass: every composed resource appears in the readiness list, status publishes a Kubeconfig secret and a cache StorageClass, and so on. These catch the behavioral drift a doc can't.
- A single canonical implementation to copy from, rather than two to choose between.
The trade-offs cut across these. Docs and skills inform but don't enforce; tests enforce behavior but not style; a canonical reference anchors style but its copies drift once edited. With only two implementations we also don't yet know what's genuinely invariant, so proving the pattern on the next provider or two (#299) before locking in enforcement likely beats designing it up front.
What problem are you facing?
InferenceClusterprovisions clusters on two clouds today: GKE viacompose-gke-clusterand EKS viacompose-eks-cluster, each a Python composition function behind an internalGKECluster/EKSClusterXR. The Ecosystem backlog has around twenty more clouds queued (#290–#305, #93, #94), with Nebius (#299) next.Each new cloud is another cluster composition function. I want to make sure our implementations don't drift as we add more. I imagine we'll lean heavily on agents to do this work.
I'm worried about two kinds of drift:
How could Modelplane help solve your problem?
I'm not sure. Some options:
The trade-offs cut across these. Docs and skills inform but don't enforce; tests enforce behavior but not style; a canonical reference anchors style but its copies drift once edited. With only two implementations we also don't yet know what's genuinely invariant, so proving the pattern on the next provider or two (#299) before locking in enforcement likely beats designing it up front.