fix(agent-pod): remote tui session for multi-agent
This commit is contained in:
@@ -72,6 +72,14 @@ spec:
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: longhorn-system
|
||||
# Longhorn writes disk state back into its own Node CRs — the disk key it
|
||||
# generates, storageReserved, diskType, evictionRequested. Git declares only
|
||||
# allowScheduling; without this the controller's writes read as drift forever.
|
||||
ignoreDifferences:
|
||||
- group: longhorn.io
|
||||
kind: Node
|
||||
jsonPointers:
|
||||
- /spec/disks
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
# Wave 6 — the model servers behind api.riotpiao.com (namespace `llm-serving`).
|
||||
#
|
||||
# Syncs before wave 7 (Kong), so the predictor Services exist before the routes
|
||||
# that point at them. KServe itself is part of the substrate; this Application
|
||||
# owns only the InferenceServices.
|
||||
#
|
||||
# Adopted from live state on 2026-08-15. These five had been `kubectl apply`-ed
|
||||
# by hand — no ArgoCD ownership, present in no repo — so every change to them
|
||||
# was drift by definition. Each manifest was exported from the cluster and
|
||||
# verified with `kubectl diff` returning empty before this file existed; the
|
||||
# first sync therefore adopted them without restarting anything.
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: llm-serving
|
||||
namespace: argocd
|
||||
annotations:
|
||||
argocd.argoproj.io/sync-wave: "6"
|
||||
spec:
|
||||
project: homelab
|
||||
revisionHistoryLimit: 3
|
||||
source:
|
||||
repoURL: https://github.com/Riotpiaole/riotpiao.homelab.com.git
|
||||
targetRevision: main
|
||||
path: k8s/apps/llm-serving
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: llm-serving
|
||||
syncPolicy:
|
||||
automated:
|
||||
# `prune: false` here, unlike every other Application in this repo, and it
|
||||
# is not an oversight.
|
||||
#
|
||||
# ArgoCD tracks ownership with the `argocd.argoproj.io/instance` label
|
||||
# (argocd-cm `application.instanceLabelKey`). KServe copies an
|
||||
# InferenceService's labels onto the Deployment and Service it generates —
|
||||
# visible today as `app.kubernetes.io/name` and `part-of` on
|
||||
# `ornith-predictor`. So once ArgoCD labels an InferenceService, KServe
|
||||
# propagates that tracking label to children that are not in git, ArgoCD
|
||||
# reads them as extraneous, prunes them, and KServe recreates them. That
|
||||
# loop churns GPU pods.
|
||||
#
|
||||
# Deleting an InferenceService therefore means deleting the file AND
|
||||
# removing the object, rather than relying on prune.
|
||||
prune: false
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
# KServe CRDs are large; server-side apply avoids the
|
||||
# "metadata.annotations: Too long" failure client-side apply hits, and is
|
||||
# the correct mode for adopting objects an operator also writes to.
|
||||
- ServerSideApply=true
|
||||
retry:
|
||||
limit: 3
|
||||
backoff:
|
||||
duration: 10s
|
||||
factor: 2
|
||||
maxDuration: 3m
|
||||
@@ -84,6 +84,29 @@ spec:
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
---
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: agent-pod
|
||||
namespace: argocd
|
||||
annotations:
|
||||
argocd.argoproj.io/sync-wave: "8"
|
||||
spec:
|
||||
project: homelab
|
||||
source:
|
||||
repoURL: https://github.com/Riotpiaole/riotpiao.homelab.com.git
|
||||
targetRevision: main
|
||||
path: k8s/apps/agent-pod
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: agent-pod
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
---
|
||||
# iMessage/SMS delivery. Raw manifests: a privileged macOS VM (Docker-OSX)
|
||||
# running the BlueBubbles server, plus its dedicated local StorageClass.
|
||||
#
|
||||
|
||||
Reference in New Issue
Block a user