Вы бы хоть " в первых строках своего письма" написали что такое ВРМ. Для меня это прочно и надолго "Виртуальное Рабоче Место" , оно же VDI- Virtual Desktop Infrastructure.
Если читатель не понял что вы подразумеваете под ВРМ- значит оно ему не надо или почему вы сразу "не договорились о терминологии" чтобы быть с читателем "на одной волне"?
1) dependencies чего- ролей? Судя по докам при этом выполнится сама роль- чего не нужно (о чем выше написано)
2) Вот тут вообще не понял причем здесь и зачем «register и when? state: started? » даже если рассматривать вариант с таской на запуск и handler на рестарт оно не надо. Почему в папете «не за раз» опишется? ресурс запускающий сервис и рестартующий ровно один, остальные его обновляют(аналог notify).
И эти примеры только-то — на что недавно наступил…
Года 1,5 приходилось писать на папете, правда еще 3 версии, задачи и условия были специфические(сначала у нас был свой орекстратор на питоне который запускал агенты на нодах в заданном порядке, потом на другом проекте писал плагин под fuel)- после него на ansible местами плеваться хочется — очень не хватает некоторых функций- вот пример:
Как вы будете переиспользовать handler какой-то роли из другого плейбука, при условии что саму роль исполнять не надо? Если сделать include в handlers -то оно не будет реагировать на notify в версии 2,2(написано в доках)- тут только финт ушами в виде include файла с описанием handler как таски или делать отдельную роль со всеми нужными handler(что, как мне кажется, через пятую точку). По аналогии с папетом- в модуле можно сделать отдельный клас для рестарта и дергать только его(без дублирования описания ресусра)
Как сказать через ansible что вот такой сервис при изменении конфига должен быть перезапущен и должен всегда быть запущен в системе? Тут только отдельный handler на перезапуск и таска на старт(иначе когда кто-то ручками остановит сервис и никаких изменений в конфиге не было- сервис так и не запустится). На папаете это будет один ресурс, который можно «обновлять» из других
Вообще такое чувство что ansible все еще сырой, в 2.2 завезли баг в yum модуле- при использовании state=latest — не ообновлялся пакет, который стоит в списке от yum checkupdate первым. Вместо того, чтобы получать список пакетов через rpmconf (как им еще ранее советовали)- опять написали кучу регулярок для парсинга yum checkupdate.
Очень двойственное чувство от ansible, если бы не отсуствие выделенного сервера- оно бы «не взлетело».
У меня на 2.2 zabbix напрямую работает с модемом — проблем не замечено, судя по докам в 2.4 это также доступно. У ваше метода со скриптом есть преимущества перед прямой работой zabbix с модемом?
Только не испортите, как произошло с альфа-клик 1.0->2.0, было все удобно обозримо и быстро доступно(проще говоря- все под рукой), затем навешали рюшечек-красивостей и удобство использования резко снизилось(на память уже не скажу, давно смотрел, вроде последней каплей стал новый интерфейс выбора шаблонов для клика/мобайла), хорошо хоть возможность использовать старый интерфейс оставили.
А вы уверены что только так и никак и никогда иначе в этих рубриках это сокращение больше не расшифровывается?
Добавить расшифровку сразу- элементарная вещь и автор уверен что его поймут правильно и читатель знает как правильно понимать.
Естественно от читателя зависит. По тому и есть правило хорошего тона сначала договориться о терминологии, а потом её применять.
Вы бы хоть " в первых строках своего письма" написали что такое ВРМ. Для меня это прочно и надолго "Виртуальное Рабоче Место" , оно же VDI- Virtual Desktop Infrastructure.
Если читатель не понял что вы подразумеваете под ВРМ- значит оно ему не надо или почему вы сразу "не договорились о терминологии" чтобы быть с читателем "на одной волне"?
2) Вот тут вообще не понял причем здесь и зачем «register и when? state: started? » даже если рассматривать вариант с таской на запуск и handler на рестарт оно не надо. Почему в папете «не за раз» опишется? ресурс запускающий сервис и рестартующий ровно один, остальные его обновляют(аналог notify).
И эти примеры только-то — на что недавно наступил…
Вообще такое чувство что ansible все еще сырой, в 2.2 завезли баг в yum модуле- при использовании state=latest — не ообновлялся пакет, который стоит в списке от yum checkupdate первым. Вместо того, чтобы получать список пакетов через rpmconf (как им еще ранее советовали)- опять написали кучу регулярок для парсинга yum checkupdate.
Очень двойственное чувство от ansible, если бы не отсуствие выделенного сервера- оно бы «не взлетело».
RateLimitInterval=30s
RateLimitBurst=1000
?