[Bug] With a pinned build ID, the controller keeps updating the Deployment after a template change
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 58/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- go, kubernetes
- 領域
- devops, infrastructure
調査の方向性
Read internal/k8s/deployments.go around NewDeploymentWithOwnerRef and internal/planner/planner.go around checkAndUpdateDeploymentPodTemplateSpec and updateDeploymentWithPodTemplateSpec. Reproduce the issue by running the unit test mentioned in the report and calling the check again after an update. Done means the template hash uses consistent inputs so the second check no longer returns the Deployment for an unchanged spec.
索引モデルが issue の本文から書いたものです。
説明
What are you really trying to do?
Change a pod template field on a WorkerDeployment that pins unsafeCustomBuildID and have it applied in place to the already-deployed version.
Describe the bug
The first update applies correctly, but then the controller detects drift on every reconcile and re-updates the same Deployment (~every 10s) until the spec changes.
The temporal.io/pod-template-spec-hash annotation is produced by hashing different inputs during creation vs update.
- NewDeploymentWithOwnerRef applies controller's envvars/volumes after hashing the template.
- checkAndUpdateDeploymentPodTemplateSpec compares against the hash of the template.
- updateDeploymentWithPodTemplateSpec hashes after applying the controller changes.
The impact is small. In my repro, the Deployment generation stayed constant across the updates without pod restarts, so the repeats are server-side no-ops. The cost is just an API write + a logline per reocncile per deployment.
Minimal Reproduction
- Create a WorkerDeployment with
unsafeCustomBuildID: stable - Change any pod template field
- Watch the controller log: "updating deployment" indefinitely
Can also be seen via a unit test: run checkAndUpdateDeploymentPodTemplateSpec again after an update and it will return the Deployment again.
Environment/Versions
- temporal-worker-controller main at 8ece977
Additional context
I have a fix ready: hash the template before applying the controller. Happy to open a PR for this!
- 主要言語
- Go
- スター
- 197
- フォーク
- 79
- 平均マージ
- 3日 4時間
- マージ済み PR（30日）
- 23
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
temporalio/temporal-worker-controller のほかの issue
-
[Feature Request] Helm chart: support topologySpreadConstraints on the controller Deployment対応中かも @akolacz が 1 日前に担当しました。 オープンhelm
temporalio/temporal-worker-controller#658 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 45/100
temporalio/temporal-worker-controller#655 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
temporalio/temporal-worker-controller#654 ·
メンテナーはふだん 1 日以内に返信
-
Bug: v1.6's delete-protection finalizer is never removed from migrated TemporalWorkerDeployment/TemporalConnection, so they stay Terminating after the v1.7 migration対応中かも @niyomukiza-mechack が 8 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 57/100
temporalio/temporal-worker-controller#644 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
AI agent skillsオープン
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
temporalio/temporal-worker-controller#633 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
temporalio/temporal-worker-controller の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
devlikeapro/waha#2322 ·
メンテナーはふだん 2 日以内に返信