Ты троллишь но как то туго получается ) дело то не в Гите, дело в том что для пуш решения по хуку, у нас почему то выливается тут в демоны и какой то кастомный протокол между ними. Считаешь норм ?

Я не троллю, я страдаю ?

Это все от любителей своих демонов и 'у нас же простой кейс, я ща свой скриптик напишу'

Это все от любителей своих демонов и 'у нас же простой кейс, я ща свой скриптик напишу'

Не хочешь пойти в яндекс работать?

Конечно нет ) там же все такие ))

Я потому и спросил ? после яндекса даже 3-й паппет не выглядит чем-то плохим или немодным. Ты бы сразу подобрел

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

Ну, может хоть пару скриптиков на перле для пинания контейнеров в подах, которые сами не поднимаются или супервизорд с 10-ю сервивами внутри каждого контейнера? Нужно же как-то страдать, нельзя так, чтобы чтобы все красиво, быстро и работало!

Ну, может хоть пару скриптиков на перле для пинания контейнеров в подах, которые сами не поднимаются или супервизорд с 10-ю сервивами внутри каждого контейнера? Нужно же как-то страдать, нельзя так, чтобы чтобы все красиво, быстро и работало!

Пострадаешь от таких как Ксения, обязательно найдутся велосипедисты. Иногда даже на департамент набрать можно

Я заметил, что чем крупнее компания - тем велосипеднее решения. Правда, некоторые из таких решений иногда выходят за пределы корпоративной инфраструктуры в опенсорсы.

И везде есть свои перегибы с разными частями инфры

кто ж поспорит

разве что Ксения :trollface:

Error 500 on SERVER: Server Error: Could not find resource 'Package['tzdata']' in parameter 'require' кто то же боролся с такой херней, когда require из хиеры едет ?

я забыл как решили тогда

Кавычки все убери

Это может помочь

сработало, охренеть

а он типа из за кавычек что тогда "внутри" получает ?

Это не очень надежно

он думает что Package['tzdata'] это как будто символ и имя ресурса прям ?

Ага

а почму не надёжно ?

ты не смотрел сигнатуру File и в частности аргумента реквайр

у них же вроде есть тип отдельный resource

или как то так

Потому, что проверка существования ресурса, которая объявлена в хиере, происходит во время формирования каталога и может случиться до того, как проверяемый ресурс будет создан

Самый смак - это понаписать кучу ресурсов в хиере с зависимостями и нотификациями, которые потом создавать каким-то циклом с Resource[$n] { ... }, а потом пытаться этот клубок безобразий заставить работать играясь с before-after-require-subscribe-notify...

а если создавать вирт ресурсы из хиеры, а в паппете в самом писать логику их связей ? )

или вирт нельзя создать их хиеры ?

Потому, что A { notify: B } работать не будет, сработает только B { subscribe: A }

или вирт нельзя создать их хиеры ?

Никогда так не пробовал

вирты же как раз сделали как костыль чтобы бороться с duplicate declaration всякими )

Тут проблема с тем, что оно пытается обратиться к еще не задекларированым ресусам ?

Ебать, ещё чуть чуть и ты изобретешь ещё один паппет агент

why not? :)

вообще почему-то у многих бывших админов страх написать несколько строчек кода

что за фигня?

инфраструктура это часть приложения

всё равно приложение - тысячи строк кода

можно маниакальное желание уменьшить кодовую базу приложения направить не на инфраструктуру, а на какие-нибудь node.js модули :)

желание убиться, но уменьшить количество инфраструктурного кода, у меня, как у разработчика инфраструктуры (не хочу мыслить как одмин, сорри!) не вызывает такого самоочевиднного отклика как у тебя, Птчел

я думаю, что ресурсы команды можно на более полезные вещи направить

это всё какое-то фанатичное красноглазие

как в руцентре в лохматых годах было с опенлдапом :))

как в руцентре в лохматых годах было с опенлдапом :))

Ну вот почему сразу в лохматых? Оно и щас себя там неплохо чувствует

решение не работающее, а простое, а теоретически и математически красивое... А кто фичи для приложения будет писать?

Ну вот почему сразу в лохматых? Оно и щас себя там неплохо чувствует

в лохматых было всё плохо :)

может, лет за 10 и дописали, я не знаю

Хотя, я не знаю - о чем ты, там очень много чего в инфре заведено на лдап

лет 6 назад это было самой популярной единой точкой отказа :)

Но-таки да, днсы в лдапе и километровые nginx.conf'ы с записаями лдаповых групп все еще имеют место быть

лет 6 назад это было самой популярной единой точкой отказа :)

Все закешировали :D

И есть медленные реплики

решение не работающее, а простое, а теоретически и математически красивое... А кто фичи для приложения будет писать?

я считаю, что птчёл недостаточно работал в стартапах :)

если у разработчика инфраструктуры в стартапе возникает желание написать блажь, что-то улучшающую в идеальном мире,

ему дают коммитить в бэкэнд

если много свободного времени

если для команды паппет агент работает плохо, можно и свой написать

а страх это сделать - это всё от старой, до девопсной парадигмы

И да, и нет

единственная реальная цена, это количество строк кода, стоимость их поддержки и стабильность (не бажность) кода

я уверена, что объём кода паппет агента просто пропадёт на фоне объёма кода приложения

Ты описываешь сейчас ту концепцию построения инфры, которая сейчас принята в яндексе

Это, конечно, очень интересно, но:

Попа болит

ну а сломать этот демон при следующем мажорном апдейте может и можно будет, но и починить можно одним коммитом

Попа болит

почему?

кодить прикольно же

прикольнее, чем руками сервера и докеры запускать

может, меня не все поймут, но мне как-то тесно в докер файле

и пайплайнах

вот

кодить прикольно же

Не прикольно когда у тебя есть 100500 различных механизмов, скриптов и машинерий, разработанных и написанных в разных проектах (но вышедших за их пределы), которые делают примерно все одно и тоже, но с разной степенью глючности и степени устаревшести. Надо налить машинку? - Не вопрос, есть три скрипта и десяток самобытных интерфейсов. Да, во все нужно сходить. Может получится не с первого раза, но попробуй еще - должно отработать.

</наболело>

Не прикольно когда у тебя есть 100500 различных механизмов, скриптов и машинерий, разработанных и написанных в разных проектах (но вышедших за их пределы), которые делают примерно все одно и тоже, но с разной степенью глючности и степени устаревшести. Надо налить машинку? - Не вопрос, есть три скрипта и десяток самобытных интерфейсов. Да, во все нужно сходить. Может получится не с первого раза, но попробуй еще - должно отработать.

интеграционные тесты решают же

почему не пишем?

писать код нужно вокруг тестов

это и про паппет кстати :)

и про самобытные демоны

это тоже другое мышление

в начале сложно

интеграционные тесты решают же

Для древней машинерии, проект которой уже закрыт, т.к. уже сделаны две более новые машинерии, которые немного хуже первой работают, но поддерживают новые конфигурации?

Для древней машинерии, проект которой уже закрыт, т.к. уже сделаны две более новые машинерии, которые немного хуже первой работают, но поддерживают новые конфигурации?

древнюю машинерию нужно выпилить

а вот живые проекты должны быть с юнит/и интеграционными тестами

древнюю машинерию нужно выпилить

Нельзя, релизы встанут

тогда переписать

вряд ли сложно

обычно говнодемоны, это ну 500 строк кода максимум

а скорее 15 :)

переписать, и насовать внутрь тестов

тогда переписать

Уже два раза переписывали, а потом - концепция устарела и сейчас разрабатываются новые машинерии.

почему переписывали без тестов?

Для новой концепции

почему переписывали без тестов?

Я не знаю, недавно работаю, пока еще не дошел до стадии "принятия"

просто с обычным кодом это тоже так: