Я в принципе так сейчас и делаю - запущен скрипт, который по inotify отслеживает изменения в локальной директории, и как только они появляются сразу их рсинкает на мастер. На нем в соседней консоли я уже apply делаю. Костыль, плюс ещё и в таком случае на мастере ломается git дерево, но я настроил чтобы при пуше в гит оно полностью перезаписывалось. Думал есть более правильный способ

как иначе то. допустим rsync, каждый локально что-то там у себя наковырял, синхронизировал с копией, запустил, "что-то" протестировал и допустим там проехало как надо, и тогда у себя локально делаем коммит пуш?

вопрос  тогда а что мы там тестировали? ведь туда каждый на'rsync'ал? то есть как минимум rsync надо уже делать в обе стороны, а зачем?

тогда уж проще коммитить каждую правку, а если потом история в гите бесит, то делать squash

Да, как только всё заработало как надо - пуш. Каждый работает над своим стейтом/формулой. Иногда бывает, что ломается что-нибудь от одновременных правок, но в песочнице это не страшно

Это долго ждать, и лишний гемор

В принципе все варианты уже описали / обсудили, но добавлю личный опыт. я  начинал с варианта с синхронизацией правок на мастер (метод синхронизации - тут уже кто во что горазд) и там прогон разрабатываемой формулы на тестовых тачках. Когда все готово - коммит в репу.

Сейчас перешел на локальное окружение для разработки на vagrant, обычно штуки 4 машины хватает для тестирования даже кластерного ПО. Скорость разработки получает сяболее  высокой. Проще сбросить окружение до чистого состояния.

Но если есть "завязки" на внешние ресурсы - тогда, вероятно, остается только синхронизация  на удаленный мастер где все настроено "почти как в проде".

Как это было у нас с предыдущей командой:
1. Стейт писался и тестировался до определённого состояния локально (кухня, salt-ssh, микро-копия целевой части инфраструктуры - зависело от человека и стейта).
2. Когда автор считал, что уже можно пробовать внедрять - мёржил стейт в мастер, но не назначал ни одному миньону.
3. Предбоевой тест: прогон через salt-call на целевой машине с -l debug test=True.
4. Если надо - доработки/правки
5. Полноценное выборочное применение стейта через salt-call
6. Если всё ок - пушили уже применение стейта целевым нодам в мастер

+

Тогда не люби голову и запускай редактор на удаленной машине. Пайчарм тот же так умеет

Ну это совсем неспортивно :) оки, я понял, тут все красиво не сделать, всем спасибо за ответы

к сожалению - да, любая разработка это боль

мне нравится идея  @Hatifnatt с локальным вагрантом

или теми же докерами - но можно потерять в целостности окружений

Не подскажете как можно оттебажить то что startup_states: sls и указанный список sls-ов не выполняется после создания миньона?
Виртуалки создаются через salt-cloud. В логе миньона ничего криминального нет.

cloud profile такой https://privatebin.net/?a30dffc95041c31d#BMcbcmBc3b1Jy6Ub6no814eQ4mJChJhSoZymQPY9FpV8

@Konstantin_Nikolaev ты вроде шаришь в salt-cloud)

Есть проблема, если docker-py установлен через pip - миньон не подхватывает модули до перезапуска, не важно указано ли reload_modules: true для pip.installed
Так же не помогает salt minion sys.reload_modules
Что добавляет странности это происходит  только если установить докер запустив отдельно стейт установки, например
salt minion-centos8 state.sls docker.server
а затем попытаться работать с докером запустив другой стейт
salt minion-centos8 state.sls docker.volumes

Если же запустить стейт установки и стейт работающий с докером в один заход - проблема не наблюдается, к примеру:
salt minion-centos8 state.sls docker.server,docker.volumes
все отрабатывает с первого раза.

Кто-нибудь сталкивался с подобным? Есть решение? Я пока не понимаю как это вообще возможно.

а что ты хотел

docker-py это секс