Reduce control-plane CRD and controller footprint (MRAP + optional providers)

[vfarcic]

What problem are you facing?

Installing Modelplane hard-depends on seven Crossplane cloud provider families (provider-aws-eks/ec2/iam/efs, provider-gcp-container/compute/cloudplatform) and activates each family's full CRD set, though the compositions instantiate only about twenty managed-resource kinds. That inflates CRD count and controller memory, the symptom reported in #323 (idle control plane at ~9GB). Two things make it worse: a BYOC-only operator who never provisions a cluster still installs the entire AWS and GCP CRD and controller surface, because the providers are hard dependencies of the Configuration; and nothing narrows the activated CRD set below the family level.

How could Modelplane help solve your problem?

Adopt Crossplane v2 SafeStart with a ManagedResourceActivationPolicy to activate only the managed-resource kinds the compositions use, leaving the rest inactive until needed, which cuts CRD count and controller footprint without removing capability. Separately, make the cloud provisioning provider families optional, via separate dependencies or a bring-your-own install profile, so operators who only register existing clusters do not install provider-aws or provider-gcp at all.

Related: #323.

[haarchri]

Thanks for raising this.
I think the upstream work proposed in crossplane/crossplane#7573 is a promising way to address this.

If that proposal is accepted and implemented in Crossplane, Modelplane could generate a ManagedResourceActivationPolicy (MRAP) for each InferenceCluster variant. Each MRAP would declare only the managed resource kinds required for that specific infrastructure (for example, EKS, GKE, or a BYOC deployment).

With Crossplane's SafeStart and MRAP support, this would mean:

• Crossplane would activate only the provider referenced by the MRAP (new: scale from 0 -> 1)
• The runtime footprint would scale with the infrastructure being used instead of the full set of providers declared by Modelplane.
• Provider controllers would start only for the managed resource kinds that are actually required. (already possible)
• BYOC-only deployments would not activate any cloud provider controllers.

This would largely address the runtime memory concerns described in #323 without requiring us to maintain separate installation profiles or manually curate provider activation. I wouldd be happy to implement per-InferenceCluster MRAP generation in Modelplane once the upstream functionality is available.