LUNA PLATFORM v.5.59.0#
Изменения LP
-
Примечание. В следующем релизе будет обновлено дефолтное значение нейронной сети для извлечения биометрических шаблонов лиц с 59 версии на 62 версию. Версия 59 будет удалена из контейнера Remote SDK.
-
Разработана утилита Storages, позволяющая проверить и/или подготовить окружение для сервисов LUNA PLATFORM v.5.46.1 и выше перед их непосредственным запуском.
В качестве подготовки окружения понимается следующее:
- Подготовка бакетов в InfluxDB для работы мониторинга
- Подготовка бакетов для сервиса Image Store, позволяющих хранить пользовательские данные (изображение, метаданные, архивы и пр.)
- Подготовка БД Influx для сбора агрегированной статистики сервисом Admin (см. раздел "Подсчет статистики выполненных запросов и оценок" в руководстве администратора)
- Подготовка баз данных, добавление функций VLMatch, создание сценариев миграции для баз данных LUNA PLATFORM (PostgreSQL или Oracle) и управление ими
- Выполнение миграции/загрузка настроек в БД Configurator
- Загрузка дамп-файлов в БД сервиса Configurator
Основное преимущество Storages перед ручной подготовкой окружения в том, что утилите известны ревизии настроек сервиса Configurator и сценарии миграции баз данных сервисов LP, что значительно упрощает процесс обновления и даунгрейда LUNA PLATFORM. Кроме того, с помощью утилиты можно оценить текущее состояние окружения LUNA PLATFORM и определить что именно будет нужно обновить.
Утилита поставляется в Docker-контейнере и может быть использована в качестве инструмента подготовки окружения LUNA PLATFORM, разворачиваемой в Docker-контейнерах, скриптом Docker Compose, системой оркестрации Kubernetes и др. Основная задача администратора - указать утилите Storages адреса баз данных, бакетов и пр.
В комплект поставки и на сайт с онлайн-документацией добавлен новый документ "Руководство по утилите Storages", описывающий принципы использования утилиты и примеры использования. Также добавлено два новых руководства по развертыванию LUNA PLATFORM - "Руководство по установке с помощью утилиты Storages" и "Руководство по обновлению с помощью утилиты Storages". Документы аналогичны обычным руководствам по установке и обновлению, за исключением того, что вся подготовка окружения выполняется с помощью утилиты Storages.
Важно! Утилита Storages находится в состоянии бета-тестирования. См. подробную информацию об утилите в руководстве по утилите Storages.
-
SDK обновлен до версии 5.18.0.
-
В политику "notification_policy" каждой задачи добавлена возможность включить отправку уведомлений о состоянии подзадач (группа параметров "subtask_callbacks").
Состояние подзадачи содержит следующую информацию:
- идентификатор подзадачи
- статус подзадачи ("in_progress", "failed", "cancelled", "done")
- количество выполненных подзадач
В ответах на запросы "get task notification policy" и "replace task notification policy" также содержится вышеописанная информация.
Уведомления о состоянии подзадач также доступны при использовании политики "notification_policy" в расписании.
-
Во все сервисы LUNA PLATFORM добавлен новый ресурс
/metrics
, позволяющий собирать и сохранять метрики в формате Prometheus в виде данных временных рядов, которые можно использовать для трекинга поведения сервиса.По умолчанию сбор метрик отключен. Сбор метрик включается в параметре "enabled" в группе "LUNA_SERVICE_METRICS". Если сбор метрик отключен, то запрос к ресурсу
/metrics
вернет ошибку с кодом "12049" и сообщением "Forbidden, Resource is disabled".Доступно два типа метрик:
request_count_total
— общее количество запросовerrors_count_total
— общее количество ошибок
Каждый из них имеет как минимум два лейбла для сортировки:
status_code
(илиerror_code
для метрик ошибок)path
— путь, состоящий из метода запроса и маршрута конечной точки
При необходимости можно добавить пользовательские типы меток, указав пару
label_name=label_value
в параметре "extra_labels" в группе "LUNA_SERVICE_METRICS".См. подробную информацию в разделе "Экспорт метрик в формате Prometheus".
-
Добавлена возможность получения X и Y координат людей при выполнении оценки количества людей.
Возможность получения координат добавлена в запросы "sdk" и политику "detect_policy" запроса "create handler". Для этого необходимо включить параметры "people_count_coordinates" и "people_coordinates" соответственно.
Структура генерируемого события также обновлена.
-
В спецификацию OpenAPI добавлены примеры для запроса "generate stream events (beta)".
-
Добавлена возможность запускать lambda GPU.
Для использования GPU необходимо включить параметр "deploy_parameters" > "enable_gpu" в запросе создания lambda.
Есть некоторые требования и ограничения при использовании GPU в Kubernetes. См. подробную информацию в разделе "Создание lambda с поддержкой GPU" руководства администратора.
Исправленные ошибки LP
-
Исправлено отсутствие поддержки метода
OPTIONS
для ресурса/plugins
. -
Исправлено появление ошибки "Internal server error", возникавшей при выполнении задачи Garbage collection с включенным фильтром
events
и параметромremove_image_origins
, когда в событии отсутствовало исходное изображение (значениеNone
). -
Исправлена ошибка
value too long for type character varying(512)
, возникавшая при выполнении даунгрейда настроек Configurator с ревизииd718e5954caf
.Изменения, внесенные в ревизии
d718e5954caf
, привели к увеличению длины строки значения настроек токенов с 512 символов до бесконечности. При выполнении даунгрейда с ревизий, где в соответствующей настройке значение длины уже было больше 512 символов, возвращалась ошибкаvalue too long for type character varying(512)
.Теперь при выполнении даунгрейда с ревизии
d718e5954caf
, значение настройки, превышающее 512 символов, будет удалено. Необходимо заново задать значение токена для соответствующей настройки. -
Исправлена ошибка
Key (name)=(<setting>) is not present in table "limitation"
, возникавшая при выполнении даунгрейда настроек Configurator с ревизииdd2641137b42
.Изменения, внесенные в ревизии
dd2641137b42
, привели к обязательной привязке каждой настройки к определенному шаблону. Для этого была добавлена новая таблицаlimitation
, содержащая ограничения. Ошибка возникала при выполнении даунгрейда из ревизий, где в базе данных Configurator уже присутствовали данные об ограничениях в таблицеsetting
и невозможно было установить связь между удаляемой таблицейlimitation
и существующей таблицейsetting
.Теперь при выполнении даунгрейда с ревизии
d718e5954caf
, все записи из таблицыsetting
будут удалены при удалении таблицыlimitation
.