---
# Ansible-side knobs for roles/k3s_app — the k3s equivalent of
# compose_stack (Unraid) and lxc_app (Proxmox): the generic role that
# deploys one *application* onto the homelab-utils cluster, as opposed to
# the k3s_* roles that deploy one *cluster service*.
#
# The distinction is worth stating, because the file layout looks similar.
# roles/k3s_metallb, k3s_monitoring, k3s_postgres and k3s_cert_manager each
# hard-code a single thing the cluster itself needs, with their config in
# defaults/ and group_vars. This role hard-codes nothing: it's driven by the
# `k3s_apps:` list in inventory/group_vars/k3s_cluster.yml and reads each
# app's config out of src/<app>/, the same src/ tree Unraid and Proxmox
# already deploy from. An app that moves between platforms gets a new
# platform vars file, not a rewrite — see CLAUDE.md → "How config is
# layered".
#
# Everything reaches the cluster the same way every other k3s role does:
# rendering a file into k3s's auto-deploying manifests directory and letting
# k3s's own controllers reconcile it. No helm binary, no kubeconfig, no
# kubernetes.core collection on the controller.

# Where k3s watches for manifests to apply. Anything written here is applied
# by k3s's deploy controller, and — importantly for remove.yml — anything
# *deleted* from here has its resources torn down again, because the
# controller tracks what each file created via an Addon CR.
k3s_manifests_dir: /var/lib/rancher/k3s/server/manifests

vault_kv_mount: kv

# Which directory under src/<app>/ansible/ holds the Kubernetes deployment.
# "kubernetes" rather than "k3s": what's in there is plain Kubernetes plus
# k3s's HelmChart CR, and an app moved to a different distribution would
# keep most of it.
k3s_app_platform_dir: kubernetes