It was swept into d5e0731 by a stray `git add -u` while amending an
unrelated commit. Nothing syncs infra/argocd, so the cluster was never
affected, but the file did not belong in that change.
The content is still reachable at d5e0731 if it is wanted back.
The Application was created with kubectl and never committed, so its chart
version, release config and values path lived only on the cluster. That made
the values-path fix a live patch: recreating the app would have restored the
old $values/gitea/runner/values.yaml and broken helm template again.
Both sources are public, so this sits alongside the other Helm-based apps
here rather than in the private repo.
The 0.91.2 bump had been sitting in Git unapplied because the app could not
generate manifests. Once the values path was fixed it applied, and Grafana
crash-looped on "Datasource provisioning error: data source not found".
Rolled back; Grafana and all 35 VMRules are healthy again on 0.77.0.
0.91.2 also moves the default dashboards and rules out of the Helm render
into a runtime sync-job, so upgrading needs a values migration and a
verified datasource config rather than a version bump.
$values resolves to the repo root, so $values/victoria-metrics/values.yaml
never existed once the manifests moved under applications/. helm template
failed on every reconcile, leaving the app permanently sync status Unknown.
gitea-runner had the same broken path but has no manifest in this repo, so
it was patched on the cluster only.
The earlier rule covered creationTimestamp, volumeMode and status but missed
apiVersion and kind, which the API server also injects into
volumeClaimTemplates. Those two alone kept both StatefulSets permanently
OutOfSync: a sync would apply successfully and report Synced, then the very
next comparison flagged them again.
A StatefulSet's volumeClaimTemplates are immutable, and the API server
injects creationTimestamp, volumeMode and a status block that are not in
the manifest. ArgoCD diffed those and reported OutOfSync permanently,
since no sync could ever resolve them.
infisical-postgres and infisical-valkey are the only StatefulSets here
using volumeClaimTemplates, which is why this app alone was affected.
Five components under applications/netbox: the web pod, an rqworker,
a daily housekeeping CronJob, postgres 18 and two valkey instances.
The task queue runs appendonly on its own PVC so queued jobs survive a
restart, while the cache instance is disposable.
Worker and cronjob override args rather than command, which replaces
CMD while keeping tini as the entrypoint, so only the web pod runs
migrations. Media, reports and scripts share one RWX PVC via subPaths
because both the web pod and the worker mount them.
Exposed on the internal gateway only.
Bumps every outdated image and chart except databases, which are
deliberately left on their current versions.
Applications:
authentik 2026.5.2 -> 2026.8.0 (server and worker)
immich v2.7.5 -> v3.1.0
gitea 1.25 -> 1.27.2
gotify 2.9.1 -> 3.0.0
uptime-kuma 2.2.1 -> 2.5.3
zipline 4.5.3 -> 4.7.0
outline 1.8.1 -> 1.9.2
reactive-resume v5.0 -> v5.2.8
netbootxyz nbxyz18 -> nbxyz24
bentopdf v2.8.2 -> v2.8.7
jellyfin 10.11.9 -> 10.11.11
gitea runner init busybox 1.37.0 -> 1.38.0
Infra:
kube-vip v0.9.1 -> v1.2.3
victoria-metrics-k8s-stack 0.77.0 -> 0.91.2
intel-device-plugins v0.35.0 -> v0.36.0
crowdsec-envoy-bouncer 0.6.3 -> 0.8.0
Immich v3 drops pgvecto.rs support. Verified the live database already
runs vchord 0.4.3 and pgvector 0.8.1 with no pgvecto.rs extension, both
inside the ranges v3 accepts, so no database change is required.
The victoria-metrics chart renamed defaultRules.create to
defaultRules.enabled at both the top level and per group. Migrated those
keys so the etcd, kubeScheduler, kubernetesSystemControllerManager and
kubernetesSystemScheduler exclusions keep applying. Without the rename
those groups revert to enabled and alert on control-plane components
that k3s runs embedded.
That chart also moved default rules and dashboards to a runtime sync job
instead of templating them, so ArgoCD will prune the VMRules and
dashboard ConfigMaps it currently owns and the job will recreate them.
kube-vip is not managed by ArgoCD. The manifest change is inert until
applied by hand.
Jeffrey