MCPRemoteProxy podTemplateSpec ports without protocol cause repeated Deployment updates
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 半日
- 初心者へのやさしさ
- 68/100
調査の方向性
Start in cmd/thv-operator/controllers/mcpremoteproxy_controller.go at remoteProxyContainerFieldsNeedUpdate and compare its port check with ContainerPortsDiffer in cmd/thv-operator/pkg/controllerutil/authserver.go. The issue also flags env, probe, and security context comparisons as possible defaulting gaps. Check or add focused tests for repeated reconciliation with an omitted port protocol; done means the Deployment no longer updates repeatedly for that case.
索引モデルが issue の本文から書いたものです。
説明
When an MCPRemoteProxy has a spec.podTemplateSpec that adds a port to the proxy container without setting protocol, the operator likely sees a difference on every reconcile and keeps updating the Deployment.
remoteProxyContainerFieldsNeedUpdate in cmd/thv-operator/controllers/mcpremoteproxy_controller.go compares the live container with the expected one built by deploymentForMCPRemoteProxy:
!equality.Semantic.DeepEqual(current.Ports, expected.Ports) ||
The expected container comes from applying the raw podTemplateSpec patch, so a port written as
ports:
- name: metrics
containerPort: 9090
has Protocol: "" on the expected side. The API server fills in TCP on the stored Deployment, so DeepEqual never matches.
I found this by reading the code while reviewing the operator port changes for the auth server TLS listener. I haven't reproduced it on a cluster. VirtualMCPServer had the same issue in that work and now treats an empty protocol as TCP when comparing ports (ContainerPortsDiffer in cmd/thv-operator/pkg/controllerutil/authserver.go). The same approach, or comparing ports with that helper, should work here. The other DeepEqual checks in that function (env, probes, security context) may have similar API-server defaulting gaps and are worth a look at the same time.
- 主要言語
- Go
- スター
- 2.3k
- フォーク
- 326
- 平均マージ
- 1日 53分
- マージ済み PR（30日）
- 155
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
stacklok/toolhive のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
stacklok/toolhive#6925 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
proxyrunner tool-filter middleware strips SEP-2322 Modern envelope from tools/list, breaking vMCP health checks再び着手できるかも @alex-feel が 46 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
stacklok/toolhive#6684 · コメント 5 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
HttpClientBuilder.Build() ignores HTTP(S)_PROXY (auth-server OAuth/DCR calls bypass forward proxy)対応中かも @schonmann が 37 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
stacklok/toolhive#6671 · コメント 2 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Delete the dead pkg/vmcp/server/adapter package再び着手できるかも @suantea が 30 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンneeds-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
Outgoing strategies differ on no-subject-provider fallback (xaa hard-fails, token_exchange and aws_sts fall back) and it is undocumented再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
stacklok/toolhive の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
-
[BUG] EphemeralJob matches every pod in the namespace when spec.selector is empty対応中かも @vishnums2k5 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
openkruise/kruise#2656 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
rancher/rancher-ai-mcp#206 ·
メンテナーはふだん 1 日以内に返信
-
test: make command and stdio startup tests portable対応中かも @dajiaohuang が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
mark3labs/mcp-go#1220 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信