Одна задача = один 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. Комментарий теперь это и описывает.
Одна задача = один 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`. Комментарий теперь это и описывает.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Одна задача = один MR: правка только комментария, поведение не меняется.
Что было не так
Комментарий утверждал, что
dependsOnработает только внутри своего ns. Это неверно и вводит в заблуждение.Как на самом деле
По CRD-схеме kustomize-controller (
api/v1/dependsOn[].namespace):То есть поле опционально и по умолчанию равно 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-opsKustomization лежат в своём 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. Комментарий теперь это и описывает.7b9de279d3to071978ccf0