AZ
Кэширование грейнсов используется на мастере?
salt-key -L | grep aldebaran сколько зарегистрированных ключей возвращает?Size: a a a
2020 December 10
VS
Не подходит для солта https://www.pypy.org/ ? Кому интересно может попробовать. Ускоренный питон.
VS
Alexander Zhukau
Кэширование грейнсов используется на мастере?
salt-key -L | grep aldebaran сколько зарегистрированных ключей возвращает?один ключ - альдебарана. Ну кэширование не отключалось.
AZ
Запустите мониторинг ивентов в отдельном терминале:
salt-run state.event pretty=True, затем выполните свой таргетинг, может это поможет понять причину проблемы. Хотя для меня странным выглядит таргетинг по fqdn, так это обычно fqdn == id minionVS
Alexander Zhukau
Запустите мониторинг ивентов в отдельном терминале:
salt-run state.event pretty=True, затем выполните свой таргетинг, может это поможет понять причину проблемы. Хотя для меня странным выглядит таргетинг по fqdn, так это обычно fqdn == id minionСпасибо. Попробую так. Таргетинг по fqdn просто для того, чтобы показать что даже такой простой и логичный таргетинг не работает.
AZ
Если у вас высоко динамичная среда, т.е. минионы создаются и удаляются часто, и используется кеширование грейнов, я допускаю, что мастер может вернуть больше target matched, чем есть на самом деле
VS
VS
вдруг кто пропустил.
VS
ну как сказать. обычный пиллар мне сразу не подошёл, т.к. не получается им динамично определять в зав-ти от условий пиллары. так что без него я лично бы не смог.
VS
если сразу сложные условия, динамичная среда и все такое, то наверное он сразу нужен, но если небольшая относительно статичная инсталляция, то обычные пиллары справляются вполне
Конечно.
MT
Вообще лучше сразу с pillarstack начинать, чтобы потом не переделывать пиллары.
Мне самому сразу так сделать.. но "если есть лоб - значит будут шишки"
Мне самому сразу так сделать.. но "если есть лоб - значит будут шишки"
2020 December 11
VS
Оказывается я напоролся на баг. Но в 3000.2 это ещё не пофикшено.
https://github.com/saltstack/salt/issues/57750
https://github.com/saltstack/salt/issues/57750
VS
Кто нибудь знает как добавить метаданные джобе при запуске ?
Пробовал так, но не могу найти эти метаданные. Либо я их не правильно задаю, либо не в том месте ищу.
Вообще идея в том, чтобы по ci во время релиза запускать батч - применять стейты. Если батч выполнится успешно - то сообщение в чат. Но хотел добавить изюминку. Версию релиза через метаданные. Возможно следую по не верному пути.
Пробовал так, но не могу найти эти метаданные. Либо я их не правильно задаю, либо не в том месте ищу.
docker exec -d -u root salt_master sh -c "salt -b 1 --failhard --metadata='{\"foo\":\"bar\"}' '*' state.highstate"Вообще идея в том, чтобы по ci во время релиза запускать батч - применять стейты. Если батч выполнится успешно - то сообщение в чат. Но хотел добавить изюминку. Версию релиза через метаданные. Возможно следую по не верному пути.
VS
спасибо. как вариант. но тогда этот пиллар будет задан только у не которых нод (которые были доступны) и всеволишь до тех пор пока кто нибудь вручную не вызовет salt без этого пиллара.
или же этот пиллар просто с каждым релизом будет переписываться и оставаться в кэше ?
я так пиллары ни когда не задавал через cmdline
или же этот пиллар просто с каждым релизом будет переписываться и оставаться в кэше ?
я так пиллары ни когда не задавал через cmdline
VS
хотя в таком даже есть смысл. может быстро узнать где какая версия накатана.
R
спасибо. как вариант. но тогда этот пиллар будет задан только у не которых нод (которые были доступны) и всеволишь до тех пор пока кто нибудь вручную не вызовет salt без этого пиллара.
или же этот пиллар просто с каждым релизом будет переписываться и оставаться в кэше ?
я так пиллары ни когда не задавал через cmdline
или же этот пиллар просто с каждым релизом будет переписываться и оставаться в кэше ?
я так пиллары ни когда не задавал через cmdline
этот пиллар будет доступен только при выполнении