You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no supported way to bounce a ToolHive-managed MCP workload.
kubectl rollout restart deploy/<name> / sts/<name> is reverted by the operator within about a second (it treats the restart annotation / template hash as drift).
The documented-looking kubectl rollout restart path therefore does nothing useful.
The only thing that actually recycles a pod is kubectl delete pod -l toolhive-name=<name>. That is not documented, and for stdio servers you have to know which pod is the proxy vs the workload.
This matters for the known vMCP memory growth (#5860): the practical mitigation is a nightly pod delete, not a rollout.
Steps to reproduce
Deploy any MCPServer or VirtualMCPServer on the operator.
honor kubectl rollout restart (ignore kubectl.kubernetes.io/restartedAt in the drift check, or re-apply it), or
document a first-class bounce: annotation on the CR (toolhive.stacklok.dev/restartedAt), kubectl annotate mcpserver …, or a condition the operator turns into a new ReplicaSet.
Actual behavior
Operator writes the Deployment/StatefulSet spec back to the desired template and the restart is gone. Users conclude “rollout restart is the runbook” and then wonder why memory/leak mitigations never fire.
Environment (if relevant)
OS/version: Talos Linux, Kubernetes
ToolHive version: operator v0.43.0 (behavior also seen on earlier 0.3x)
Additional context
Related: #3329 (replica scale-back). #5860 (vMCP leak — current workaround is kubectl delete pod -l toolhive-name=…, because rollout restart is a no-op).
Happy to take a docs-only fix if product intent is “never mutate child workloads”; then the CR annotation / thv command needs to exist so GitOps and CronJobs have something legal to do.
No credentials or private hostnames in this report.
Bug description
There is no supported way to bounce a ToolHive-managed MCP workload.
kubectl rollout restart deploy/<name>/sts/<name>is reverted by the operator within about a second (it treats the restart annotation / template hash as drift).kubectl rollout restartpath therefore does nothing useful.The only thing that actually recycles a pod is
kubectl delete pod -l toolhive-name=<name>. That is not documented, and for stdio servers you have to know which pod is the proxy vs the workload.This matters for the known vMCP memory growth (#5860): the practical mitigation is a nightly pod delete, not a rollout.
Steps to reproduce
MCPServerorVirtualMCPServeron the operator.kubectl rollout restart deploy/<name> -n <ns>kubectl get deploy <name> -n <ns> -o yaml | grep restartedAt(or watch ReplicaSets).Expected behavior
Either:
kubectl rollout restart(ignorekubectl.kubernetes.io/restartedAtin the drift check, or re-apply it), ortoolhive.stacklok.dev/restartedAt),kubectl annotate mcpserver …, or a condition the operator turns into a new ReplicaSet.Actual behavior
Operator writes the Deployment/StatefulSet spec back to the desired template and the restart is gone. Users conclude “rollout restart is the runbook” and then wonder why memory/leak mitigations never fire.
Environment (if relevant)
Additional context
Related: #3329 (replica scale-back). #5860 (vMCP leak — current workaround is
kubectl delete pod -l toolhive-name=…, because rollout restart is a no-op).Happy to take a docs-only fix if product intent is “never mutate child workloads”; then the CR annotation /
thvcommand needs to exist so GitOps and CronJobs have something legal to do.No credentials or private hostnames in this report.