KP
зависит от того как у вас устроены пилары
Size: a a a
2020 January 31
KP
у нас есть десяток топ переменных и внутри словари
KP
то есть все пилары это 10-20 нестед словарей
KP
а не 100500 flat variables
J
Ну, если словари целиком пихать из пилларов, то да, неплохо. За пиллары рассыпухой я бы расстреливал перловкой
KP
и в контекст передаем просто словарь или ключ словаря
J
понятно, ну, тогда не настолько все грустно)
KP
условно говоря ВСЕ перемнные которые использует state elasticsearch лежат в ключе elasticsearch
J
условно говоря ВСЕ перемнные которые использует state elasticsearch лежат в ключе elasticsearch
Ну это прямо-таки основы. Иначе будет полный бардак, бонусом еще и можно напересекаться при сложных инклюдах и получить на выходе черт знает что.
KP
и можно сделать типа salt-call pillar.get elasticsearch и посмотреть сразу весь словарь - очень удобно
KP
повех этого pillarstack с deep merge всего
J
В общем, я все примерно так же и юзал, только без контекстов. pillar.get только для микростейтов и быстрых костылей.
Не запариваетесь сторонние формулы редактировать и потом мейтнейнить с таким объемом правок?)
Не запариваетесь сторонние формулы редактировать и потом мейтнейнить с таким объемом правок?)
KP
не используем сторонние формулы вообще
KP
и никому не советую 🙂
J
А если их читать перез накатом? 😂
KP
особенно если их читать перед накатом
GG
то есть все пилары это 10-20 нестед словарей
+++
GG
ну мы используем контекст для того что бы явно обьявить скоуп переменных внутри шаблона. Вызовы pillar.get и прочее внутри запрещены
Это как ?
KP
ну пункт про "запрещено" никак не энфорсится солью если вопрос в этом, но на ревью ловим и бьем по рукам
GG
думаю, если удалить нафиг контекст и сделать в шаблоне salt['pillar.get'], все будет прекрасно работать
Я просто этого дерьма распихал ровным слоем, но пока не страдаю от этого