Господа, а кто, что имеет сказать за handlers vs register? Когда handler-ы оправданы, а когда register? Общие соображения такие (дальше - полотенце, сори): - handler-ы шарятся между ролями, значит, что в случае конфликта имен, сделав nofity в одной роли, можно случайно дернуть handler другой роли, который делает не то, что мы ожидали - по-умолчанию, в случае нескольких сработавших handler-ов, если какой-то один падает, то все остальные не срабатывают - по-умолчанию, без force_handlers, если в одном таске вызвался notify на срабатывание handler-а, а следующий task свалился, то handler не сработает и это может привести к неконсистентному состоянию - при следующем проигрывании изменений не будет -и handler-ы уже не сработают - порядок вызова handler-ов гарантировать нельзя - по сути порядок определяется их порядком следования в файле, где они объявлены, а не порядком вызовов notify - если в play-е, при подключении ролей, одни роли опираются на другие роли и подключаются в определенном порядке, то роли, которые играются позже могут сфейлиться, т.к. таски от notify еще не сработали (они срабатывают в конце play-я) и получается, нужно знать какие handler-ы и в каких ролях живут (инкапсуляция страдает), чтоб разнести такие роли по разным play-ям. - meta: flush_handlers позволяет дернуть все handler-ы, но тогда вопрос, почему одна роль влияет на то, как работают другие роли? пользовалю, который проигрывает плейбук хочется детерминированного поведения и когда он видит, что вроде бы играется одна роль, а потом из-за flush_handlers начинают работать таски других ролей, которых в текущей проигрываемой роли никак быть не могло, то это введет в заблуждение. - в ansible можно играть плейбук пошагово начиная с какого-то таска - с тасками последовательность шагов будет такой, как объявлено в плейбуке и ролях, а в случае handler-ов - не понятно, какой будет порядок выполнения - на handler-ы не распространяется serial —- итого - кажется, что register + отдельный таск постабильнее и понадежнее будут

Все становиться проще когда в 1 роль не впихивают все что только в голову пришло. Раздроби все по ролям, сделай их независимыми друг от друга

Дак разные роли разные хендлеры они не пересекаются

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

Но это нужно учитывать при написании и обкатывать роли

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

И registry у меня тоже есть кое где. Но это не про хендлеры же совсем

вот есть у меня конфиг nginx-а. я его меняю, потом хочу сделать reload nginx-у. могу это сделать через registry + отдельный таск, а могу через handler-ы. вопрос про плюсы-минусы обоих вариантов

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

Ты ведь не на прод сразу гонишь

А от retry не пробовал запустится?

А от retry не пробовал запустится?

велосипед?

И это обязательно в 1 подход разве?

Про ребут машине не ясно зачем, ядро сменить?

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

Не... Плейбук не для этого. Плейбук это не скрипт make_everything.sh или test_all.sh

Можно ведь тегами обмазать все

а какие аргументы? для меня плейбук - это слепок окружения. надо новое такое же окружение - поменял инвентори и готово

инвентори в контексте ансибла это окружение и перменные, но не плейбуки

теги ведь не спасут от невызвавшихся хендлеров - просто селективное выполнение тасков

инвентори в контексте ансибла это окружение и перменные, но не плейбуки

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

чтобы нагляднее было смотри на верх. упало в роли charm к примеру

там по роли на play. так, конечно все работать будет. неудобство - на каждый play - сбор фактов