3 Commits

Include renames

Author	SHA1	Message	Date
hermesandgrachevko	12ad1c040c	chore(security): поправить комментарий про dependsOn в ESO (#12) ... Одна задача = один MR: правка только комментария, поведение не меняется. **Что было не так** Комментарий утверждал, что `dependsOn` работает только внутри своего ns. Это неверно и вводит в заблуждение. **Как на самом деле** По CRD-схеме kustomize-controller (`api/v1/dependsOn[].namespace`): ``` namespace: description: |- Namespace of the referent, defaults to the namespace of the resource object that contains the reference. ``` То есть поле опционально и по умолчанию равно namespace **самого объекта Kustomization**, а не namespace, куда тот раскидывает ресурсы. Поэтому «зависимости из другого ns» бывают двух разных видов: - в `ewatkins/talos-cluster` все app-Kustomization лежат в `flux-system` (`apps/default/netbox/ks.yaml`: `namespace: flux-system`, `targetNamespace: default`), поэтому `dependsOn` на `dragonfly` и `crunchy-postgres-operator-*` пишется без поля `namespace`, хотя рабочие нагрузки уезжают в другие ns; - в `drag0n141/home-ops` Kustomization лежат в своём target-ns (`apps/ai/toolhive/ks.yaml`: `namespace: &namespace ai`), и там кросс-ns зависимости пишутся явно: `onepassword-connect` с `namespace: external-secrets`, `pocket-id-instance` с `namespace: security`. **Что у нас** Наш репозиторий следует второму варианту: `kubernetes/apps/<ns>/kustomization.yaml` задаёт `namespace: <ns>`, то есть app-Kustomization живут в своём ns. Значит зависимости между `ai` и `database` (Dragonfly CR → dragonfly-operator) будут писаться с явным `dependsOn[].namespace`. Комментарий теперь это и описывает.Reviewed-on: #12 Co-authored-by: Hermes Agent <hermes@grachevko.ru>	2026-09-17 21:18:22 +00:00
hermes	df78e7ce51	fix(security): CR ESO в отдельный Kustomization после оператора	2026-09-17 18:18:33 +00:00
hermesandgrachevko	07c32f9f79	feat(security): External Secrets Operator + ClusterSecretStore на Vault	2026-09-17 18:15:35 +00:00