---
# System prepended metadata

title: Dynamic constraints and other ADCM improvements

---

# 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 кластера в страничку со статусами и ссылками: 
* добавить стейты, мультистейты, 
* разбивку компонентов по хостам, 
* состояния, полученные от агента


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