[FEATURE] Built-in tool to wait for Kubernetes resource conditions
Nessuno ha ancora preso questa issue.
- #58 di @moezdil — chiusa senza merge
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Inizia individuando gli entry point degli strumenti Kubernetes integrati esistenti e il modo in cui invocano i comandi, quindi confronta le loro interfacce con gli input proposti per k wait: tipo di risorsa, nome, namespace, condizione e timeout. Il lavoro è completato quando una singola chiamata bloccante restituisce un risultato chiaro di successo o timeout/fallimento senza un ciclo di polling dell’agente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
[Main discussion and idea from alexis-brettes (Nayero): https://discord.com/channels/1346225185166065826/1346225185841221644/1497163015047352361]
Add a built-in tool that blocks until a k8s resource reaches a given condition, using k wait under the hood. This removes the need for agents to poll repeatedly and saves a significant number of tokens.
When an agent deploys something and needs to wait for it to be ready, it currently has to call k get in a loop until the resource reaches the desired state. Each loop iteration is a full LLM turn, which wastes tokens and adds latency.
Current pattern:
[turn 1] kgp -n default -> Pending
[turn 2] kgp -n default -> Pending
[turn 3] kgp -n default -> Running
Proposed Solution
A tool that wraps k wait and returns only when the condition is met or the timeout expires:
k wait deployment/myapp -n default --for=condition=Available --timeout=300s
The tool would accept: resource type, resource name, namespace, condition, and timeout. It makes one blocking call and returns a clear success or failure message. No polling loop, no extra LLM turns.
This is related to kagent-dev/kagent#1541 but targets a specific and common use case: waiting for k8s resources rather than waiting for a fixed amount of time.
- Lingua principale
- Go
- Stelle
- 36
- Fork
- 29
- Merge medio
- 3g 23h
- PR unite (30g)
- 3
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di kagent-dev/tools
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
kagent-dev/tools#87 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
kagent-dev/tools#54 ·
-
[FEATURE] Add a limit parameter to k8s_get_resources to bound context growthForse già presa @anjosluc l’ha presa 21 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
kagent-dev/tools#82 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 78/100
kagent-dev/tools#80 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
kagent-dev/tools#69 · 1 commento ·
Tutte le issue di kagent-dev/tools
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
vanderheijden86/b9s#20 ·
-
go-battery needs an ndsctl on PATH: TestPurchaseSessionGuardHoldsThroughTheOutcomeUnknownWindow fails on bare hosts (passes with stub)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
OpenTollGate/tollgate-module-basic-go#726 ·
I maintainer di solito rispondono entro 1 giorno
-
ux waiting for feedback
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
evcc-io/evcc#34527 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
phase:v3 type:harness
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno