поясню что я хочу по-другому

в роли есть некий код который нужно гарантировано  остановить  до того как ктото другой станет мастером
1. shutdown
2. manual/automatic new leader election

вот две ситуации,  в обоих случаях я не знаю как это сделтаь

Тогда стейтфул сделает всё как надо. Ну и фенсинг в помощь

вот мой изначальный вопрос
https://t.me/tarantoolru/169719

т.е.  apply  вызывается в правильном порядке ?    .. т.е. сперва на старом мастере RO  потом на новом RW   так?

>  сперва на старом мастере RO  потом на новом RW   так?

да

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

при условии что старый (текущий) мастер жив естественно

В общем случае нет. Пример такой:
старый мастер уходит в ридонли нормально
старый мастер начинает apply_config всех ролей по-очереди, но одна из них виснет, не дойдя до нужной вам.
новый мастер делает wait_ro + wait_lsn успешно, и делает apply_config is_master = true

Что нужно сделать:
Тот файбер, о котором вы говорите, который надо остановить, должен сам следить за box.info.ro и сам отрубаться. Ну или по крайней мере паузиться пока опять не станет rw

" уходит в ридонли нормально"  что значит нормально ?     разве не через  apply_config    ему должны сказать что он уходит в RO  ?

вот я описал два случая,  мне нужно в обоих случаях иметь возможность "закомитить транзакции"  до того как он станет RO,    что мне делать?

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

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

вот код роли vsahrd storage   насколько мне известно именно vsahrd переключает ro-rw,    если  в lifecycle statful есть  выделеное состояние  когда  все узлы репликасета RO       то из этого  когда должно ровно следовать правило что сперва apply_config переводит текущий в RO  после чего и только после этого может на новом мастере сделать apply_config  с флагом что он мастер...

если ты говори что в общес случае не так,  то получается чтото не сходится совсем https://t.me/tarantoolru/169754

apply_config - не обязательно атомарная операция. Картридж сначала выполняет box.cfg({read_only = true}), потом apply_config каждой роли. А они и йилдят бывает.

ну хорошо, ro выставляется по харду до  всех apply ,  это я понял ,  допустим это произошло при SIGTERM ..

а как оно работает при  manual/automatic new leader election ?    
там тоже сперва по харду   выставляется    box.cfg({read_only = true})    и только после этого  вызываются все  apply_config ?

т.е.  до роли vshard  о том что он не rw уже постфактум конфиг доходит?

да

как насчет того чтобы в api ролей добавить hook   который нужно подергать перед тем как в ro переводить ?

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

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