odoo-tower/cluster-platform-v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(eso): chart 0.7.1 — explicit CRD defaults to clear ArgoCD OutOfSync

Browse Source 
ArgoCD was reporting all 6 ExternalSecrets as OutOfSync because the
live CRs had conversionStrategy/decodingStrategy/metadataPolicy fields
filled in by the CRD defaults that werent in the chart manifests.
Stamping them explicitly so the diff is clean. Tower UI will now show
Provisioning state correctly transition to Ready.
This commit is contained in:
OdooSky v3
2026-05-07 21:47:00 +03:00
parent c26ee5b3c6
commit ff7eb9fafc
7 changed files with 45 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
templates/longhorn.yaml
View File

@@ -1,17 +1,19 @@
{{- if .Values.longhorn.enabled }}
# Tenant data StorageClass. Tower's instance overlays don't pin a
# storageClassName today (they let the cluster default decide). Phase
# 1 of ADR 0003 just defines this class so Phase 2/3 can flip new
# instances to bind here without further chart changes.
# Tenant data StorageClass. Tower's instance overlays bind here in
# Phase 6 (Tower stamps storageClassName=longhorn-tenants on new
# instance PVCs). Existing instances on local-path stay where they
# are — Longhorn additive, doesn't replace.
#
# `replicaCount` comes from values; Standalone tier ships replicas=1
# (durability is hourly S3, not local mirrors).
# (durability is hourly S3 backup, not local mirrors).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-tenants
annotations:
# Not the cluster default in Phase 1 — explicit opt-in only.
# Not the cluster default — explicit opt-in only via Tower's
# PVC-stamp logic. (Two default storage classes is a k8s
# misconfig; k3s already provides local-path as default.)
storageclass.kubernetes.io/is-default-class: "false"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
@@ -25,8 +27,8 @@ parameters:
fsType: "ext4"
{{- end }}
# NOTE: The CSI VolumeSnapshotClass (snapshot.storage.k8s.io/v1) lives
# in Phase 3 of ADR 0003, alongside the Tower code that consumes it.
# It depends on the external-snapshotter CRDs which Longhorn does not
# ship — they're a separate install. Adding it here would fail the
# initial sync on a fresh cluster. Phase 3 will land both together
# (snapshotter CRDs + VolumeSnapshotClass + Tower VolumeClone path).
# in Phase 3 of ADR 0003, alongside the Tower code that consumes it
# AND the external-snapshotter CRDs (which Longhorn does not ship —
# they're a separate install). Adding VolumeSnapshotClass here would
# fail the initial sync. Phase 3 lands all three together: snapshotter
# CRDs + controller + VolumeSnapshotClass + Tower VolumeClone path.