Concern
В ADCM реализовано уведомление пользователей в виде concern. Такие concern-уведомления возникают, например, в случае некорректной конфигурации, когда не заполнены поля обязательных параметров в конфигурациях сервисов, компонентов либо других объектов. Другим примером, при котором ADCM создает concern-уведомление, является ситуация, когда после изменения конфигурации объекта пользователь забывает применить ее на хостах кластера и продолжает работу с устаревшей конфигурацией.
Причины возникновения concern, а также их типы и свойства подробно описаны ниже.
Типы concern
В ADCM есть три типа concern:
-
Flag
-
Lock
-
Issue
Concern всех типов отображаются в UI.
Concern могут быть блокирующими либо неблокирующими. Если concern является блокирующим, то для связанного с ним объекта ADCM недоступны какие-либо action и обновления. В UI блокирующие concern обозначаются красным цветом, а неблокирующие — желтым.
Рассмотрим каждый из типов отдельно.
Flag
|
ВАЖНО
Concern типа flag доступны только в том случае, если это поддерживается использующимся продуктом.
|
Flag (флаг) — это неблокирующий concern, который указывает на некоторое событие.
Флаги подразделяются на два типа:
-
встроенные (embedded);
-
кастомные (custom).
Кастомные флаги создаются с помощью плагина Ansible adcm_change_flag. Встроенные флаги создаются каждый раз, когда наступают соответствующие события.
Одним из событий, которое может привести к появлению флага, является устаревание конфигурации на хостах после изменения параметров объекта в ADCM без последующего применения. Чтобы устранить concern, необходимо применить изменения на хостах кластера, выполнив соответствующие действия (action).
Причина (cause) concern типа flag отображается в UI. В случае рассмотренного выше события сообщение имеет следующий вид: <Object> has a flag: outdated configuration.
Цель возникновения concern типа flag для рассмотренного выше события — исключить взаимодействие с объектами, конфигурация которых устарела на хостах, а также обеспечить возможность гибкой настройки порядка выполнения action для взаимосвязанных сервисов. Например, изменение конфигурации уже установленного сервиса может потребовать его перезапуска. В этом случае ADCM создает concern типа flag, который напоминает пользователю о необходимости выполнения перезапуска.
Lock
Lock — это блокирующий concern, который возникает каждый раз при запуске action на объекте. При этом элементы UI и API, связанные с объектом, становятся недоступны.
Причина concern типа lock отображается в UI в виде следующего сообщения: Object was locked by running job <job>.
Цель возникновения concern типа lock — предотвратить одновременный запуск нескольких action пользователем.
Issue
Issue — это блокирующий concern, который может быть вызван несколькими причинами:
-
У объекта есть незаполненные либо невалидные поля в его конфигурации. Эта причина отображается в UI в виде следующего сообщения:
<Concern owner> has an issue with its config. -
Объект содержит сервис с обязательным импортом. Эта причина отображается в UI в виде следующего сообщения:
<Concern owner> has an issue with required import. -
Для работы кластера требуется установить обязательный сервис. Эта причина отображается в UI в виде следующего сообщения:
<Concern owner> has an issue with required service. -
Объект содержит сервис, для работы которого требуется установить другой сервис. Эта причина отображается в UI в виде следующего сообщения:
<Concern owner> has an issue with requirement. Need to be installed: <target service>. -
В объекте не настроен маппинг между хостами и компонентами. Эта причина отображается в UI в виде следующего сообщения:
<Concern owner> has an issue with host-component mapping.
Цель возникновения concern типа issue — предотвратить некорректное взаимодействие и работу объектов.
Источники concern
У concern существует источник (owner). Источник concern типа flag и issue — это объект ADCM, на который воздействует этот concern.
В UI источник concern демонстрируется во всплывающем окне с сообщением о причине рядом со значком concern.
У concern типа lock источником является соответствующая задача (job).
Приоритизация и наследование concern
Если у объекта ADCM есть несколько concern, один из которых — блокирующий, то блокирующий concern обладает более высоким приоритетом. Значок concern всегда окрашивается в цвет более приоритетного concern.
Также concern могут наследоваться объектами от других объектов. Например, если concern есть у хостпровайдера, то он может быть унаследован хостом, созданным с помощью этого хостпровайдера.
Между родительским и дочерним объектами concern наследуются в обе стороны. Объекты находятся в родительско-дочерних отношениях, если между ними существует явная иерархическая связь. Если concern есть у сервиса, то он наследуется как кластером, содержащим этот сервис, так и компонентом, который содержится в этом сервисе. Concern сервиса не наследуется хостами, если компоненты сервиса не добавлены на хост. При этом, если concern есть у кластера, содержащего хост без компонентов, то этот concern кластера не будет унаследован хостом, пока на этом хосте не появится хотя бы один компонент. Аналогично, в случае появления concern на хосте без компонентов он не будет передаваться кластеру, содержащему этот хост.
Concern типа flag у сервиса не распространяется на другие сервисы в кластере. Concern типа lock и issue распространяются от хоста на компоненты, которые находятся на хосте, даже если источником concern является другой родительский объект: кластер, сервис, компонент или хостпровайдер.
Если удалить объект-источник concern, то будут удалены и concern всех связанных с ним объектов (как родительских, так и дочерних). Например, если удалить из кластера сервисы, которые содержат concern, то у кластера эти concern тоже исчезнут. При этом concern, источником которых является сам кластер, не исчезнут.
Запуск действий в неблокирующем режиме
Начиная с версии ADCM 2.5.0 доступен запуск действий для всех объектов ADCM без блокировки самих объектов. Это значит, что в результате запуска действия могут быть созданы неблокирующие concern, которые не препятствует параллельному запуску других действий для данного объекта, его родительских или дочерних элементов.
Запуск действия в неблокирующем режиме на примере действия Install statuschecker:
-
На вкладке Hosts в таблице найдите хост и нажмите на иконку
. -
Из выпадающего списка выберите Install statuschecker.
-
В открывшемся диалоговом окне переведите переключатель Raise non-blocking concern в активное состояние.
Запуск действия в неблокирующем режиме -
Ознакомьтесь с текстом предупреждения и нажмите Next.
-
Установите флажок Verbose, чтобы просмотреть дополнительную информацию о выполнении действия на странице Jobs, и нажмите Run.
В результате успешного запуска действия будет создан неблокирующий concern типа flag. В столбце Concerns отобразится иконка
. При наведении курсора на иконку появляется всплывающее окно с описанием ошибки, которое имеет вид <Object> has a flag: running job <job>, где<Object>— наименование объекта,<job>— название действия.
Страница Hosts при запуске действия в неблокирующем режиме
Удаление неблокирующих concern
В ADCM у пользователей с ролями Cluster Administrator, Service Administrator, Provider Administrator и ADCM Administrator есть возможность удалять неблокирующие concern на следующих вкладках:
-
Clusters
-
Services
-
Components
-
Hostproviders
-
Hosts
Описание вкладок приведено в следующих статьях:
Чтобы удалить созданный неблокирующий concern, выполните следующие шаги:
-
Перейдите на нужную вкладку.
-
В списке напротив объекта, для которого необходимо удалить неблокирующий concern, наведите курсор на иконку
. -
Во всплывающем окне с описанием ошибки нажмите на иконку
.
В результате иконка перестанет отображаться напротив соответствующего объекта, а также появится следующее сообщение: The concern has been deleted.