Коллеги, добрый день, у меня небольшой вопрос: А что дает ключ

—env у команды werf bundle apply? Если в werf converge он задавал имя namespace и чарта, то в werf bundle apply заметил, что развертывание происходит в namespace default, а новый namespace вообще не создается

> Если в werf converge он задавал имя namespace и чарта Всё так, он использовался по умолчанию при формировании release-name / namespace-name (JFI шаблон можно изменить в werf.yaml) и chart-app-name в случае, когда мы имеем Git-проекта (werf render / werf converge / ...). Когда же мы используем bundle, конечный артефакт, отвязанный от Git, env влияет только на моменты второго плана: доступна в чарте бандла в служебных переменных, а также добавляется дополнительной аннотацией ко всем ресурсам.

тогда совсем ламерский вопрос: я как то могу дернуть project-name из werf.yaml для указания —namespace в werf bundle apply? Мб какая то переменная есть?

Зачем вы используете бандлы, если на этапе развёртывания у вас есть git-проекта?

у нас есть старые k8s кластера, на которых pipeline организован с помощью werf converge и появляются новые, на которых будет Flux. Планируем Flux'ом деплоить через oci бандлы. У Flux будет отдельная монорепа, а oci бандлы будет собирать и отправлять в registry с помощью werf bundle publish. Проекты постепенно будем переводить на новые кластера, но необходимо сохранить возможность развертывания на старые. Планирую в старые кластера также деплоить через бандлы, только уже без flux

Скоро подвезём интеграцию Flux + Nelm -- сможете катать Helm-чарты со всеми нашими фичами. $ werf helm get-autogenerated-values --stub-tags | yq .werf.name project-name

Хм, я и сейчас катаю ваши бандлы 🤔

Да, но нет. Вы по сути катаете обычные Helm-чарты, а вся функциональность werf поверх остаётся за бортом, т.е. то, что выкатывалось с werf, не факт, что доедет с Flux в вашем случае. Наша цель -- идентичное поведение при выкате с помощью werf converge / werf bundle apply и при использовании Flux (по сути pull и push подходов).

Есть такое ага, пришлось отказаться от werf secret

А на ArgoCD такой глубокой интеграции так не будет?🥺

Для Flux мы просто пишем контроллер и всё нативно встраивается. В случае с ArgoCD из нативности мы уже выжили максимум и дальше только fork и перепил по аналогии с Helm и Nelm.

В арго не очень хорошо сделано. Там у них свой кастомный деплоер, которые везде прибит к арго. Простого способа подменить его нет, только форк (но боюсь это будет очень сложной задачей). С Helm у них те же проблемы, их деплоер часть фич Helm-чартов/шаблонов не поддерживает. Пока решение по Argo не приняли, надо глубже разбираться.

Вся суть в том, что у argo по итогу даже хельм используется только для рендера. Т.е. если научить werf закидывать аннотации sync-wave то это конечно не dependOn, но хоть какой-то порядок и минус рутина. А я все жду kustomize в werf... когда же случится? Когда мы сможем юзать patches?

Всё же у нас сейчас большая часть плюшек подсистемы развертывания находится непосредственно в деплое ресурсов (трекинг и прочее), т. е. либо мы встраиваем Nelm в argo, либо учим argo всему тому же, что умеет Nelm (нереально), либо вот вариант с CR-ками. Просто werf render туда принести смысла особо нет. По sync-wave, может я неправильно понял, но у нас есть werf.io/weight (то же самое, что волны), и теперь ещё werf.io/deploy-dependency. По kustomize пока не добрались, правда для патчинга там скорее всего будет что-то такое, а не kustomize

😳 может всё-таки нормальный кастомайз читать? И просто его рендерить. Тогда и helm можно рендерить через него, иногда. Мы очень давно такую связку используем, как такового helm нет в кластерах.