# Dynamic constraints and other ADCM improvements

### Проблемы

1. Отсутствие ~~динамического дефолтного значения~~, возможности получить актуальное значение, например:
ha + kerberos_enabled -> flink.sasl=true
ha + kerberos_disabled -> flink.sasl=false
Значение параметра нельзя откатить к дефолту, если "дефолт" определяется в процессе экшна, включает проверку состояния объектов.

Таким параметрам нельзя разрешить кастомизацию без отдельного экшна или галки use custom value, иначе пользователь на non-read-only параметре может через кнопку откатиться к статическому дефолту, который может оказаться некорректным для текущего состояния объектов.

2. Использование мультистейтов для реализации логики приложений неудобно:
1. Разброс источников сведений о состоянии объектов.
До появления мультистейтов и, в некоторых случаях, до сих пор изменения логики опирались на проверку конфига кластера/бандла:
Пример - действия по if и when в бандле (when cluster.config.kerberos_client.enable_kerberos и тп).
Относительно новая логика,например, HA, может использовать мультистейты: если мультистейт ha_on отсутствует/удален, удалить znode ha-сервиса

2. Параметр конфига и мультистейт отличаются количеством допустимых состояний:
1.Конфиг имеет 2 состояния: записан или не записан
2.Мультистейт имеет 3 состояния: наличие (true), отсутствие (false) или faulty, при этом оно не отражает реальное состояние объекта. Например, faulty_kerberized из-за чеков.
Использование мультистейта затрудняет описание логики: нужно уточнять, faulty считать как true или как false?

3. Faulty-состояние - костыль, заменяющий retry и чек
... и, возможно, пометку need action (need action) для отложенных действий?

Faulty не производит отката изменений конфига.

3. Слишком много экшнов

4. Динамические констрейнты отсутствуют
1. На уровне HC-map нельзя выяснить, сколько нужно RM для Yarn в зависимости от HA_mode. Сложная логика

### Варианты решения

1. Jinja-переменные вместо жестко заданных дефолтов

2. Убрать мультистейты? - пока рано. Нужно при смене конфигов реализовать смену мультистейтов. При чеках - тоже. Узнать все места, где меняются статусы.

3. Фильтрация экшнов
1. Если не использовать мультистейты для реализации логики приложения, то их цель - фильтрация экшнов.
2. Экшнов слишком много, нужна группировка в один экшн Manage:
1. Manage cluster - набор галочек в модалке, перечисляющих допустимые экшны над кластером
2. Manage object - набор галочек с допустимыми экшнами над сервисом, компонентом (MVP) и, в дальнейшем, хостом
3. Доступность галочек экшнов для должна определяться дополнительным параметром - или мультистейтом, или параметром конфигурации, например, kerberos_enabled или kerberos_disabled. Т.к. не успеем проверить весь конфиг кластера на керберизацию при запуске модалки, нужен заранее записанный параметр.
4. Возможность заменить мультистейты ~~интерактивными модальными окнами~~ агентом

Нужно знать состояние объектов - введение агента.

4. Динамические констрейнты в HC-map - продумать
1. Добавить кнопку Manage HC map: туда добавить добавление, удаление, перемещение
2. Сделать REST для смены констрейнтов

### Заметки
Не hc-mapa, а delete-service используется для удаления замапленных экшнов

Переделать Main кластера в страничку со статусами и ссылками:
* добавить стейты, мультистейты,
* разбивку компонентов по хостам,
* состояния, полученные от агента

Экшны хоста добавить.
Переход от экшнов хоста к экшнам сервиса