причём тут руби если рофлят на JS

это ж про жс

Ксения как обычно, поверхам хватанула, и то мем пятилетней давности

у них вообще клёвые доклады

глянь про жизнь и смерт жаваскрипта

Господа

Никогда не работал с наследованием можете немного пояснить?

class test::test {$temp_dir = hiera('check::temp_dir')} class test2 inherits test::test { $test2 = $temp_dir file {"$test2" content => template('test/test.erb'), } }

Примерно такого типа конструкция

Где я не прав?

Суть положить в первый класс определения и в последующих их каждый раз переопределять

Inherits работает как включение

Ну в принципе он же позволит переопределить несколько раз для каждого класса?

Нет, это как бы инклуд

Ок хорошо инклюд но если я в каждом последующем классе буду инклюдить только один изначальный и переопределять $test3 = $temp_dir $test2 = $temp_dir

Это ок?

Или есть другой путь?

Ну попробуй

Я не понимаю зачем тебе тогда наследоваться если можно просто параметризировать

У тебя ресурсы классов все равно потом выпадут в общий каталог и если что приведут к дупликейт деклорейшн

Не не суть этой балалайки в екзеке питон файла потом

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

Хочу их обьявить в изначальном классе и в каждом последующем переопределять ну и генерить последовательно из темплейта этот скрипт

Может можно как-то проще но я хз

Ну так зови из каждого класса , параметры положи в хиеру в хиере в иерархии используй коллинг класс переменную

У тебя в результате изнутри класса каждый раз экзеку этому будут разные параметры переданы.

У тебя в результате изнутри класса каждый раз экзеку этому будут разные параметры переданы.

Ну в принципе примерно такой результат и хочу

Ну так зови из каждого класса , параметры положи в хиеру в хиере в иерархии используй коллинг класс переменную

Вот тут немножко не понял

У тебя к примеру 2 класа , тест 1 и тест 2. Ты в классе формируешь строку аля $args которая делает всегда lookup(::var). В хиере в иерархии ты добавляешь слой в котором используешь переменную calling_class_path и раскладываешь в test1.yaml одно значение vars в test2 другое

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

Да я понял здесь у меня один ямл

Но сразу говорю это депрекейтид с 5й версии хиеры

Ничего страшного у меня 3.6 папет

У тебя ж там старье какое то ?

Короче идею я конечно понял

Но несколько ямл файлов не вариант в данном случае

Аха, потому и советую...

Тогда как ты хочешь ?

Да видимо буду дрочить inherits или include

Звать разные куски хеша огромного в разных местах ? Так вобще не проблема если знаешь ключ

В 3.6 был advanced syntax со звёздочкой? Что бы хеш передать в ресурс и таким образом параметризировать его ?

В 3.6 был advanced syntax со звёздочкой? Что бы хеш передать в ресурс и таким образом параметризировать его ?

Щас гляну

$file_ownership = { "owner" => "root", "group" => "wheel", "mode" => "0644", } file { "/etc/passwd": ensure => file, * => $file_ownership, }

$file_ownership = { "owner" => "root", "group" => "wheel", "mode" => "0644", } file { "/etc/passwd": ensure => file, * => $file_ownership, }

Да это я уже нашел

Но не понятно как тут запилить переопределение

Ты можешь дергать хеш и потом просто по ключу часть его как параметры в ресурс кидать

Зачем переопределение ? У тебя хеш огромный, каждый набор именован. И ты по ключу этот набор берешь.

Зачем переопределение ? У тебя хеш огромный, каждый набор именован. И ты по ключу этот набор берешь.

Не я видимо не так обьяснил

Ничего страшного у меня 3.6 папет

хм, много модулей уже не работают?

В паппете нет наследования с переопределением. Это ломает логику стейт машины. Все переопределения только через хиеру

В паппете нет наследования с переопределением. Это ломает логику стейт машины. Все переопределения только через хиеру

можно через промежуточную переменную же

:))

но это криво

можно через промежуточную переменную же

Это новая переменная ничего не переопределяется

Это новая переменная ничего не переопределяется

ну вот ты новую в модуле и юзаешь

а импортированную нет

а импортированную нет

Ну вот примерно так

вставляешь там иф импортерт перменная столько-то, то тогда присвоить используемой, иначе другое :)

Ну вот примерно так

так лучше не делать, а через хиеру переопределять

как вообще жизнь на 3.6?

мне кажется, всё сломалось уже, или нет?

так лучше не делать, а через хиеру переопределять

Очень хорошо у меня мелкий питон скрипт такого типа with open('<%= @filename -%>', 'U') as f:

Я хочу в него из одного манифеста передавать много значений

наверное, почти все модули переопрелелены в паппет файлы на старые версии?

или нет?

мне кажется, всё сломалось уже, или нет?

Ничего не сломалось

Очень хорошо у меня мелкий питон скрипт такого типа with open('<%= @filename -%>', 'U') as f:

совсем ужас. Это надо через факт делать

кастом факт

совсем ужас. Это надо через факт делать

Предлагаешь мне нафигарить фактов на одну ноду?

Предлагаешь мне нафигарить фактов на одну ноду?

зачем делать из паппета... солт?

зачем делать из паппета... солт?

Вопросы к небу проблему не решают

просто если делать через Ж, потом будут новые проблемы :(

Поэтому я и спрашиваю насколько я прав в следующей логике Есть хиера с параметрами. Параметр забираем в один манифест в котором лежит изначальный класс где обьявляем параметр типа $test В манифест кладем второй класс который наследует первый класс и где переопределяем параметр как $test2 = $test Добавляем третий класс и поступаем схожим образом $test3 = $test

Заведется нет?

просто если делать через Ж, потом будут новые проблемы :(

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

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

почему не факты?

а импортированную нет

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

почему не факты?

Инсталляция может лежать по разному пути тоесть это мне еще сверху чекер для фактов писать?

Пути задаются в большом ямле

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

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

Логично просто если это коненчо возможно напилить инклюды а содержимое для реплейса в питон скрипте подпихивать из ямла

Инсталляция может лежать по разному пути тоесть это мне еще сверху чекер для фактов писать?

ну и подхватывай путь из ямла, что такого?

часть через кастом факты

часть через ямл

кастом факты для того и сделали - динамически получить переменную

точнее факт :)

точнее факт :)

Какой факт?

Какой факт?

твой

Что у меня есть blalbalba.xml?

Так я и так это знаю

Что у меня есть blalbalba.xml?

например

Логично просто если это коненчо возможно напилить инклюды а содержимое для реплейса в питон скрипте подпихивать из ямла

У тебя этот скрипт один реализуется или их 10 на одной ноде должно получиться ?

У тебя этот скрипт один реализуется или их 10 на одной ноде должно получиться ?

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

Точнее он есть этот скрипт он простой как топор

Тупой серч с реплейсом

Суть не плодить дохера манифестов с россыпью классов

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

ну и генери факты из хиеры

что такого?