Add PodTemplateSpec to MCPRemoteProxy

[ChrisJBurns]

Summary

MCPRemoteProxy is the only workload CRD missing a PodTemplateSpec field. MCPServer, VirtualMCPServer, and MCPRegistry all have one, allowing users to customize pod-level settings (node selectors, tolerations, security contexts, sidecars). MCPRemoteProxy users have no way to configure these.

Current state

MCPRemoteProxy (cmd/thv-operator/api/v1alpha1/mcpremoteproxy_types.go, lines 36-139):
Has Resources and ServiceAccount fields but no PodTemplateSpec.

MCPServer (cmd/thv-operator/api/v1alpha1/mcpserver_types.go, lines 219-227):

// +optional
// +kubebuilder:pruning:PreserveUnknownFields
// +kubebuilder:validation:Type=object
PodTemplateSpec *runtime.RawExtension `json:"podTemplateSpec,omitempty"`

Same pattern exists in VirtualMCPServer (lines 52-60, container name vmcp) and MCPRegistry (lines 41-49, container name registry-api).

MCPServer also defines validation conditions:

• ConditionPodTemplateValid = "PodTemplateValid" (line ~21)
• ConditionReasonPodTemplateValid = "ValidPodTemplateSpec" (line ~56)
• ConditionReasonPodTemplateInvalid = "InvalidPodTemplateSpec" (line ~59)

What to change

1. Add field to MCPRemoteProxySpec (cmd/thv-operator/api/v1alpha1/mcpremoteproxy_types.go)

Add the PodTemplateSpec field to MCPRemoteProxySpec, following the exact pattern from MCPServer:

// PodTemplateSpec defines the pod template to use for the MCPRemoteProxy
// This allows for customizing the pod configuration beyond what is provided by the other fields.
// Note that to modify the specific container the remote proxy runs in, you must specify
// the appropriate container name in the PodTemplateSpec.
// This field accepts a PodTemplateSpec object as JSON/YAML.
// +optional
// +kubebuilder:pruning:PreserveUnknownFields
// +kubebuilder:validation:Type=object
PodTemplateSpec *runtime.RawExtension `json:"podTemplateSpec,omitempty"`

Ensure "k8s.io/apimachinery/pkg/runtime" is imported.

2. Add condition constants (cmd/thv-operator/api/v1alpha1/mcpremoteproxy_types.go)

Add condition type and reason constants following the MCPServer pattern:

ConditionTypeMCPRemoteProxyPodTemplateValid = "PodTemplateValid"

ConditionReasonMCPRemoteProxyPodTemplateValid   = "ValidPodTemplateSpec"
ConditionReasonMCPRemoteProxyPodTemplateInvalid = "InvalidPodTemplateSpec"

3. Add validation in controller

In the MCPRemoteProxy controller (cmd/thv-operator/controllers/), add PodTemplateSpec validation following the MCPServer controller pattern. Search for PodTemplateValid or PodTemplateSpec in mcpserver_controller.go to find the validation logic to replicate.

4. Add pod template merge logic

In the MCPRemoteProxy deployment/pod builder, add logic to merge the PodTemplateSpec override into the generated pod spec. Follow the same pattern used by MCPServer — search for podTemplateSpec in mcpserver_controller.go to find the merge logic.

5. Update tests

Add unit tests for PodTemplateSpec validation (valid/invalid cases) and pod template merging. Use the MCPServer tests as a reference.

6. Regenerate and verify

task gen
task crdref-gen
task lint-fix
task lint
task test

Notes

• This is a non-breaking additive change — the field is optional with omitempty.
• The runtime.RawExtension type with PreserveUnknownFields allows the full Kubernetes PodTemplateSpec without needing to mirror all its types in the CRD schema.
• The MCPServer implementation is the canonical reference for how to implement this.

Generated with Claude Code