---
# GitLab cross-site replication Phase 2b (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - exposes each
# of home's 3 existing Gitaly nodes individually to the VPS, so Praefect
# can register the VPS as a 4th node in the SAME virtual storage and
# inter-Gitaly replication RPCs can reach each node directly. Per-pod
# (not per-StatefulSet), unlike the chart's own gitlab-gitaly-default
# Service - Praefect/Gitaly must address each node individually, not
# load-balance across them.
#
# Reached over the same public UniFi WAN forward already used for
# Postgres, NOT the Netbird mesh directly - confirmed live the direct-
# Netbird-IP path doesn't accept inbound connections to home (same gap
# already present for the existing etcd quorum; the earlier assumption
# that NodePort binds on a reachable Netbird interface was wrong).
# Targets Gitaly's TLS port (8076), not the plaintext one (8075) -
# Gitaly's gRPC has no built-in transport security, and this WAN hop
# would otherwise carry the gitaly_token, gitlab_shell_secret, and raw
# repository contents in plaintext. See gitaly-tls-certificate.yaml and
# global.gitaly.tls.enabled in values.yaml.
apiVersion: v1
kind: Service
metadata:
  name: ha-gitaly-0
  namespace: gitlab
spec:
  type: NodePort
  selector:
    statefulset.kubernetes.io/pod-name: gitlab-gitaly-default-0
  ports:
    - port: 8076
      targetPort: 8076
      nodePort: 32446
---
apiVersion: v1
kind: Service
metadata:
  name: ha-gitaly-1
  namespace: gitlab
spec:
  type: NodePort
  selector:
    statefulset.kubernetes.io/pod-name: gitlab-gitaly-default-1
  ports:
    - port: 8076
      targetPort: 8076
      nodePort: 32447
---
apiVersion: v1
kind: Service
metadata:
  name: ha-gitaly-2
  namespace: gitlab
spec:
  type: NodePort
  selector:
    statefulset.kubernetes.io/pod-name: gitlab-gitaly-default-2
  ports:
    - port: 8076
      targetPort: 8076
      nodePort: 32448