да я понимаю, но като же можно ему настройки передать чтобы руками настроить

просто по факту примеров нет ни в доке картрижда ни в операторе

Есть апи Cartridge. Оно описано тут https://www.tarantool.io/en/doc/latest/book/cartridge/topics/failover/#failover-configuration

ну да есть failover_set_params   ,     пока не понятно в какой момент его использовать но это ладно,   более насущный вопрос - это как правильно  пробросить настройки   чтобы потому их установить через эту фнукцию

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

делая в лоб я просто примонтирую в поду конфигмапу с  json файлом,  потом   при инициализации возьму fio read ,   прочитаю  файл с настройками и весь хрен,    но думаю что это сильно далеко от того что себе представляли процес настройки те кто это проектировал

В конфиге есть секции, определяемые идентификатором поля первого уровня. Приложения и роли добавляют обработку своих секций. Конфиг со всеми секциями прилетает на фазе настройки ролей в колбэк "apply_config". Также есть колбэк для предыдущей фазы валидации "validate_config". В этом колбэке в соответствующей роли вытаскивается из прилетевшего объекта нужная секция по её имени и дальше с ней происходит работа.

etcd:
    hosts:
    - 127.0.0.1:5000
    - 127.0.0.1:5001
    - 127.0.0.1:5002

Вот так будет примерно выглядеть секция в конфиге для гипотетической роли, которая что-то делает с etcd

Самая главная особенность конфига — это двухфазный коммит. Он даёт гарантию что на всех работающих узлах кластера будет применён одинаковый конфиг

разве это не должно быть настройкой роли  failover-coordinator ?  
в доке сказано что это нужно через cartridge.failover_set_params    елать, при этом в доке картриджа   маскируется наличие роли failover-coordinator   , она какатоя опциональная чтоли, т.е .  ее явно не нужно объявлять а просто настроить (при этом непонятно в какой момент),         соответственно я делаю предположение что настраивать это нужно еще до запуска всех ролей.

в любом случае меня интересует официальная позиция о том как в операторе предполагается объявлять то что прилетает в apply/validate_config     ,    
это первый вопрос,  
второе  как предполагается настраивать то что до момента запуска ролей происходит  тоесть близко к моменту cartridge.cfg
...

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

Сейчас оператор управлять clusterwide конфигом не умеет.
На это есть тикет: https://github.com/tarantool/tarantool-operator/issues/67

Эм, failover и failover-coordinator - это разные вещи, от слова совсем. Вы хотите одну сущность (stateful failover) настроить с помощью другой сущности: failover-coordinator, так не работает

допустим,  
если говорить про пример kv/key-value-store

есть ли какойто "официальный" workaround что можно сделать в инсталяции helm  чтобы :
- a)  в поле conf_new     добавить   хоть что нибудь conf_new.wow ~= nil
- б)  куда в примере примере kv/key-value-store  засунуть строку cartridge.failover_set_params()
- в)  куда засунть то что сувать в  etcd2_params

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

нет, скриншот про другое, я понимаю что  это нужно настраивать где то в другом месте,   про это и вопрос

curl -H 'Content-Type: application/json' --data @failover.json http://server:port/admin/api

А в json кладете graphQL запрос с нужными настройками, например

так картридж к этому моменту уже должен быть запущен  получается, мне кажется что stateful failover  это то что должно быть настроено сильно раньше чем стартуют пользовательские  роли

Это не так, вы же можете в интерфейсе каржа включать фейловер и даже выключать!?

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

Еще раз в целом:
1. Оператор сейчас не умеет управлять кластер-вайд настройками, медицинский факт.
2. самый простой способ - после того как калстер поднялся - дернуть его через curl или из тестов встроенным http.client и запихнуть ему конфиг failover. Далее этот конфиг персистится и при перезапусках его еще раз дергать не надо.