# lakekeeper 배포 테스트 전용 오버라이드 — custom-values.yaml 위에 얹어서 쓴다.
# 목적: DB(cnpg-cluster) 연결 여부만 확인한다. custom-values.yaml의 auth.oauth2는
# 실제 운영 keycloak(https://keycloak.example.org/realms/paasup)을 가리키므로,
# 격리된 테스트 네임스페이스에서는 도달 불가능해 파드가 기동하지 못한다.
#
# lakekeeper values.yaml 주석(line 492-494): auth.oauth2.providerUri가 비어 있고
# auth.kubernetes.enabled가 false면 인증 자체가 꺼진다 — 이 테스트에서 노리는 상태.
#
# custom-values.yaml의 catalog.extraVolumes(keycloak-tls)는 root-ca-secret을 참조하는데
# 이 시크릿도 실제 keycloak 배포 시에만 생성되는 것이라 격리된 테스트 네임스페이스에는
# 없다 — db-migration Job의 init 컨테이너가 FailedMount로 멈춘다. oauth2를 끄면서 이 볼륨도
# 같이 비운다(Helm은 배열 값을 병합하지 않고 통째로 교체하므로 빈 배열로 덮어써야 한다).
#
# 카탈로그의 실제 권장 설정(custom-values.yaml)은 변경하지 않는다.
auth:
  oauth2:
    providerUri: ""
    audience: ""
    ui:
      clientID: ""
      scopes: ""

catalog:
  extraEnv: []
  extraVolumeMounts: []
  extraVolumes: []

  # custom-values.yaml의 host(lakekeeper.example.org)는 이 클러스터에 실제 배포된 다른
  # lakekeeper 인스턴스(defense-llm 네임스페이스)가 이미 쓰고 있다 — 같은 host로 배포하면
  # apisix에 동일 host의 라우트가 2개 등록되어 실제 서비스의 트래픽 라우팅과 충돌한다
  # (실측 — apisix admin API에 두 서비스가 동일 host로 동시 등록된 것 확인).
  # 배포 테스트는 반드시 별도 host를 쓴다.
  ingress:
    host: "lakekeeper-access-test.example.org"