# PaaSup custom-values — longhorn
#
# 실측 기반 리소스 튜닝만 담는다. replica 수는 노드 수에 따라 [1,3] 으로 클램프해야 하므로
# 소비 측(dipup 의 longhorn-values.yaml.tpl)에서 주입한다 — 여기에 고정값을 두지 않는다.

# longhorn-manager 는 차트 기본값이 resources: ~ 이라 QoS 가 BestEffort 가 된다.
# 스토리지 컨트롤 플레인이 노드 압박 시 가장 먼저 밀려나므로 request 를 명시한다.
#
# limit 은 CPU·메모리 모두 두지 않는다:
#  - CPU: 볼륨 attach/detach·리빌드 구간에서 throttling 되면 상태 전이가 지연된다.
#  - 메모리: manager 메모리는 전체 Longhorn CR 의 informer 캐시라 볼륨·replica 수에
#    거의 선형 증가한다(38 replica 기준 ~260Mi 실측). 규모를 모르는 클러스터에 고정 limit 을
#    걸면 OOM 루프 위험이 있고, admission webhook 이 manager 안에 있어 OOM 루프는
#    곧 모든 Longhorn CR 쓰기 차단 = 볼륨 작업 전면 중단이다.
# request 만으로도 목적(스케줄 보장·eviction 보호)은 달성된다.
# priorityClass 는 차트 기본값 longhorn-critical 이 이미 적용된다.
longhornManager:
  resources:
    requests:
      cpu: 100m
      memory: 384Mi

defaultSettings:
  # instance-manager 파드가 노드 allocatable CPU 중 예약하는 비율(%).
  # 차트 기본값 12 는 8~16 코어 노드(≈1~2 코어)를 가정한 값이라 코어 수가 큰 노드에서는
  # 과다 예약이 된다(32 코어 → 3840m, 실측 사용량은 ~100m).
  # 5% 로 낮춘다: 32 코어 → 1600m, replica 38 개 기준 실사용 대비 약 16 배 여유.
  # v2(SPDK)는 폴링 방식이라 코어를 상시 점유하므로 기본값 12 를 유지한다.
  #
  # 주의 1: 비율이라 저코어 노드에서는 절대값이 작아진다(8 코어 → 400m). 코어 수가 작은
  #         노드에 배포할 때는 상향을 검토할 것.
  # 주의 2: running engine instance 가 있으면 Longhorn 이 즉시 적용을 거부하고
  #         applied=false 로 staged 한다 — 해당 노드 볼륨이 전부 detach 될 때 실현된다.
  #
  # instance-manager 메모리는 의도적으로 무제한이다(Longhorn 이 v1 IM 에 메모리 limit 설정을
  # 노출하지 않는다). IM 메모리는 호스팅 인스턴스 수에 비례하며(replica 당 ~40Mi,
  # engine 18 + replica 26 → 1062Mi 실측), IM 이 OOMKill 되면 해당 노드의 모든
  # engine/replica 프로세스가 동시에 죽어 볼륨 전체가 내려가고 리빌드가 필요하다.
  guaranteedInstanceManagerCPU:
    v1: "5"
    v2: "12"

  # CSI 사이드카·플러그인도 차트 기본값이 무설정이라 BestEffort 가 된다.
  # 실측(attacher/provisioner/resizer/snapshotter 각 1~2m·13~16Mi, csi-plugin 2m·42Mi)
  # 기준으로 여유를 둔 request 를 부여한다.
  # Longhorn 이 JSON 문자열로 파싱하므로 반드시 문자열로 전달해야 한다
  # (차트가 이 값을 toJson 없이 quote 만 하므로 map 으로 주면 깨진다).
  #
  # 이쪽은 limit 을 유지한다 — 재시작 내성이 있어서(프로비저닝/attach 가 잠깐 멈출 뿐
  # 데이터 경로 영향 없음) 누수 백스톱의 이득이 손실보다 크다. 다만 사이드카 캐시도
  # PVC/VolumeAttachment 수에 따라 증가하므로 실측의 약 16 배로 여유를 크게 잡는다.
  #
  # ⚠️ 운영 주의: 이 값을 바꾸면 csi-provisioner 가 재시작하고, 재시작 직후 resync 에서
  #    보류 중이던 PV 삭제가 flush 된다(dev 실측: 재시작 4분 뒤 reclaimPolicy=Delete 인
  #    Released PV 12개 삭제). 변경 전 Released/Failed PV 목록을 먼저 확인할 것.
  systemManagedCSIComponentsResourceLimits: >-
    {"csi-attacher":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
    "csi-provisioner":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
    "csi-resizer":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
    "csi-snapshotter":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
    "longhorn-csi-plugin":{"requests":{"cpu":"20m","memory":"64Mi"},"limits":{"memory":"512Mi"}},
    "node-driver-registrar":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}},
    "longhorn-liveness-probe":{"requests":{"cpu":"10m","memory":"32Mi"},"limits":{"memory":"256Mi"}}}