stacklok/toolhive

Bug description The operator logs this on a timer even when zero MCPRegistry objects exist in the cluster: Warning: MCPRegistry is deprecated and will be removed in a future release; install the ToolHive registry server via the toolhive-registry-server Helm chart (https://github.com/stacklok/toolhive-registry-server) instead logger=controller-runtime/cache On v0.43.0 we see it about every 6 minutes from deploy/toolhive-operator, mixed into the VirtualMCPServer reconcile logs. It is a cache/informer warning, not an event on a CR, so it cannot be silenced by not installing the CRD users already do not use. Steps to reproduce Install ToolHive operator v0.43.0. Do not create any MCPRegistry. kubectl logs deploy/toolhive-operator -n <ns> | grep MCPRegistry Expected behavior If no MCPRegistry CRs exist, do not warn. If the CRD is still registered, warn once at startup (or when the first CR appears), not on every cache resync. Actual behavior Periodic warning forever on clusters that nev

Status Fix PR: #6376 Maintainer direction (PROXIES column, do not fold into SERVERS): #6342 (comment) PR announcement: #6342 (comment) Reply to maintainer: #6342 (comment) PR cross-link comment: #6376 (comment) Bug description kubectl get mcpgroups prints a SERVERS column from .status.serverCount. That field only counts MCPServer members. A group that contains only MCPRemoteProxy objects (or a mix) looks empty / wrong: status.remoteProxyCount / status.remoteProxies are populated status.serverCount / status.servers are unset the table column therefore shows a blank SERVERS value Operators then think the group has no members, even though vMCP discovery and the CR status both know about the proxies. Steps to reproduce Create an MCPGroup (empty spec is enough). Create one or more MCPRemoteProxy objects with spec.groupRef.name pointing at that group. Do not add any MCPServer. Wait until the group is Ready. kubectl get mcpgroup <name> -n <ns> kubectl get mcpgroup <name> -n <ns

Summary The deletion specs in the mcp-oidc-config integration suite fail intermittently on CI. The failure looks structural rather than random: the controller rechecks a blocked deletion on a 30s requeue, and the suite's Eventually timeout is also 30s, so a spec passes only if reconcile lands inside whatever margin is left. Loaded runners lose that race. Evidence Run 30574241215, three attempts against the same commit: Attempt Result Spec that failed 1 action_required - 2 failure should be deleted after MCPRemoteProxy reference is removed 3 failure should be deleted after VirtualMCPServer reference is removed A different sibling failed on each attempt, both timing out at exactly 30.000s. The same suite passes locally. Mechanism MCPOIDCConfig deletion is blocked while workloads still reference it, and rechecked on a fixed requeue: // cmd/thv-operator/controllers/mcpoidcconfig_controller.go:241 // Requeue to check again later return ctrl.Result{RequeueAfter: 30 * time.Secon

Use case We run MCP servers via the operator on EKS + Karpenter. To cut provisioning cold-start latency we keep a dedicated pre-warmed node pool, tainted workload-class=mcp-warm:NoSchedule, and steer the MCP server pod onto it using spec.podTemplateSpec (a matching toleration + nodeAffinity). That works well for the server. But each MCPServer also spawns the proxy (proxyrunner) Deployment, and there's no way to give the proxy pod the same scheduling. resourceOverrides.proxyDeployment currently supports only annotations/labels/env/imagePullSecrets — no nodeSelector/tolerations/affinity. So the proxy is repelled by the warm-pool taint, always lands on a cold general node, and forces a fresh node boot (~40s) that dominates provisioning latency and trips our readiness watch. Net: the server is warm but the proxy is cold, so we hit the cold-start anyway. What we need A way to set nodeSelector, tolerations, and affinity on the proxy Deployment via the MCPServer CR — matching the capabili

Problem MCPServerReconciler builds the proxy container's environment variables in two places that must be kept byte-for-byte identical: deploymentForMCPServer — constructs the env for the live Deployment. deploymentNeedsUpdate — re-derives the expected env slice and equality.Semantic.DeepEquals it against the live container to detect drift. Both assemble the same nine sections in the same order: # Section 1 OpenTelemetry (TelemetryConfigRef) 2 Token exchange (ExternalAuthConfigRef) 3 OBO secret (ExternalAuthConfigRef) 4 Webhook (WebhookConfigRef) 5 OIDC client secret (OIDCConfigRef inline) 6 ResourceOverrides.ProxyDeployment.Env 7 Redis password (SessionStorage) 8 THV_MCPSERVER_GENERATION (downward API) 9 Embedded auth server Because DeepEqual on the env slice is order- and content-sensitive, any env var added to the builder but not mirrored into the drift check (or added at a mismatched position) causes the controller to detect false drift on every reco