Make golden snapshot bake concurrency configurable, and tell the caller whether an actor restored from a golden or booted from the image

オープン
#3,484 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
46/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
gcp, go, kubernetes

調査の方向性

Start by tracing the template reconciler's golden-bake worker pool and the actor startup path; look for existing configuration flags and metrics to follow. The issue names no files or tests, so locate the relevant entry points before estimating the change. Done means bake concurrency is configurable, callers can tell whether an actor restored from a golden or booted from an image, and the bake backlog is exposed as a metric.

索引モデルが issue の本文から書いたものです。

説明

area/api-machinery area/lifecycle kind/feature
What happens today

The template reconciler bakes goldens with a fixed pool of five workers per ateapi replica; a bake is about two minutes (boot, readiness wait, upload). Template creation has no such limit, so a job that derives thousands of templates quickly leaves the bakes far behind. While a template has no golden, its actors boot from the image, and nothing on the actor says so.

Templates created Time to create Backlog
8,101 9 min 45 min later most had no golden; every actor had booted
36,000 45 min about 20 h on 2 replicas, about 7 h on 12

Scaling ateapi to twelve replicas was the only lever, which ties the bake rate to API replica count by accident.

Proposal
  • Make the bake concurrency a flag.
  • Report on the actor whether it started from a golden or booted from the image.
  • Expose the bake backlog as a metric, so a caller can wait for it.
How to see it
  1. Create a few thousand ActorTemplates quickly, one per image, golden snapshots enabled.
  2. kubectl-ate get actor-templates -a ATESPACE; count empty golden tags over time. Create actors meanwhile: none produce a restore record.
  3. Scale ateapi; the rate changes proportionally.
Setup

Setup: two GKE worker pools. Pool A: 40 x n2-standard-8 (8 vCPU, 32 GiB, Intel Cascade Lake), 192 GB pd-balanced boot disk, 320 worker pods. Pool B: 783 x e2-standard-8 (8 vCPU, 32 GiB, AMD Rome), 500 GB pd-balanced boot disk, 2,000 worker pods. ateapi at 2 to 12 replicas; Postgres on one n2-standard-16 with pd-ssd. Images: SWE-bench Verified (445, about 1.1 GB compressed median, 13 layers), R2E-Gym-V1 (8,101, 0.57 GB compressed median, 1.9 GB max, 14 layers, almost no layer sharing), a 36,871-image SWE-RL set (0.5 to 1.4 GB compressed median per subset, up to 13 GB squashed single-layer images); unpacked size 2 to 2.5 times compressed; plain containerd pulls from a same-region Artifact Registry. gVisor (runsc), GKE 1.36.4-gke.2046002, Container-Optimized OS, Linux x86_64. Observed on Substrate 0fdb67b5; the code cited is unchanged on main at a508f8fe.

主要言語
Go
スター
6.1k
フォーク
676
平均マージ
2日 2時間
マージ済み PR(30日)
522

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

agent-substrate/substrate のほかの issue

agent-substrate/substrate の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。