Перейти к содержанию

LUNA PLATFORM v.5.64.0#

Изменения LP

  • Добавлена возможность задать время жизни (TTL) для объектов в бакетах (как локальных, так и S3).

    TTL для объектов рассчитывается относительно формата времени GMT.

    TTL для объектов задается в днях следующими способами:

    • во время создания бакета для всех объектов сразу (основная политика TTL бакета)
    • после создания бакета для конкретных объектов с помощью запросов к соответствующим ресурсам

    Количество дней выбирается из списка в соответствующих запросах (см. ниже).

    Кроме количества дней параметр может принимать значение "-1", означающее, что нужно хранить объекты вечно.

    Настройка основной политики TTL бакета

    Основную политику TTL бакета можно настроить следующими способами:

    • с помощью аргумента --bucket-ttl для скрипта lis_bucket_create.py. Например, "python3 ./base_scripts/lis_bucket_create.py -ii --bucket-ttl=2".
    • с помощью запроса к сервису Image Store. Например, "curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-samples?ttl=2".

    Настройка TTL для конкретных объектов

    TTL для конкретных объектов можно настроить с помощью параметра "ttl" в следующих местах:

    • в политиках "storage_policy" > "face_sample_policy", "body_sample_policy" и "image_origin_policy" обработчика
    • в запросах "create object", "create images" и "save sample"

    Если параметр "ttl" не задан, то будет применена основная политика бакета, в котором находится объект (cм. выше).

    Поддерживаемые облачные провайдеры

    Поддерживаются облачные провайдеры Amazon S3, облачное хранилище Яндекса и MinIO.

    Добавление TTL к существующим объектам

    Добавить TTL для существующего конкретного объекта можно с помощью PUT-запросов к ресурсам /objects, /images, /samples/{sample_type} сервиса Image Store.

    Добавить TTL к основной политике бакета (ко всем существующим объектам в бакете) можно с помощью PUT-запроса к ресурсу /buckets сервиса Image Store.

    Для бакета, расположенного в S3, необходимо выполнить миграцию с помощью скрипта "base_scripts/migrate_ttl_settings" сервиса Image Store. Это связано с тем, что для TTL объектов в S3 применяется через фильтры, связанные с тегами. Команда выполнения миграции бакетов в S3 приведена в руководстве по установке. См. подробную информацию о миграции бакетов S3 в разделе "Миграция для добавления TTL к объектам в S3" в руководстве администратора.

    Окончание TTL

    Когда TTL объекта подходит к концу, то он помечается для удаления. Для локальных бакетов выполняется задача очистки 1 раз в день (в 01:00 утра). Для бакетов S3 используются внутренние правила настройки TLL.

    Обратите внимание, что между датой истечения срока действия и датой фактического удаления объекта может возникнуть задержка. Как для локального хранилища, так и для S3.

    Поиск истекающих объектов

    Чтобы узнать, когда срок действия объекта истекает, можно использовать запросы с методами HEAD к ресурсам /objects и /images. Эти запросы возвращают заголовки ответов X-Luna-Expiry-Date, в которых указана дата, когда объект больше не подлежит сохранению.

    См. подробную информацию в разделе "TTL для объектов" в руководстве администратора.

  • Теперь сервис Handlers будет отправлять только одно уведомление, если у пользователя есть два callback-а с одинаковыми настройками.

    Если пользователь создал два callback-а, которые отличаются только фильтрами, система отправит уведомление только один раз, даже если событие удовлетворяет обоим фильтрам.

    Например, если настроено два callback-а в одну стороннюю систему с различием только в том, что у одного callback'a установлены фильтры по прохождению Liveness, а у другого по достижению определенного уровня "similarity", то при генерации события, удовлетворяющего обоим фильтрам, во внешнюю систему придет только одно уведомление.

    Это позволяет легче реализовывать логику отправки уведомлений при соблюдении определенных фильтров.

  • Добавлена возможность отправки уведомлений о состоянии задач и подзадач в Telegram.

    Отправка уведомлений в Telegram реализована за счет добавления нового типа callback'ов telegram в политику "notification_policy" каждой задачи.

    Для отправки уведомлений необходимо указать параметры chat_id и token.

    Отправку уведомлений в Telegram также можно настроить при создании расписания для задач.

  • Во контейнерах всех сервисов обновлена версия Python до 3.12.

    Поддержка более старых версий Python прекращена.

  • В параметры запроса "video analytics (beta)" добавлен параметр "video" > "orientation" > "angle", отвечающий за возможность поворота видео на угол 90, 180 или 270 градусов перед его обработкой.

  • Добавлена возможность использовать более безопасный алгоритм для генерации JWT токенов.

    По умолчанию сервис Accounts использует алгоритм HS256 для подписи JWT-токенов. При необходимости можно использовать асимметричное криптографическое шифрование с помощью алгоритм ES256.

    Для этого необходимо: - сгенерировать закрытый ключ ECDSA - закодировать закрытый ключ в формат Base64 - установить переменные окружения "ACCOUNTS_JWT_ECDSA_KEY" и "ACCOUNTS_JWT_ECDSA_KEY_PASSWORD"

    Важно! Переключение алгоритма подписи с HS256 на ES256 (или наоборот) оказывает значительное влияние на проверку токенов. Все существующие токены, подписанные предыдущим алгоритмом, станут недействительными после внесения изменений. Это происходит потому, что механизм проверки подписи токена ожидает, что структура и криптографическая база токена будут соответствовать новоуказанному алгоритму.

    См. раздел "Алгоритмы JWT-токенов" в руководстве администратора.

  • Добавлена возможность шифрования паролей и токенов, передаваемых в задаче Estimator и в политике "notification_policy"

    Для этого необходимо при старте контейнера сервиса Tasks передать пользовательские значения переменным окружения FERNET_PASSPHRASE и SALT.

    • FERNET_PASSPHRASE — пароль или ключ, используемый для шифрования данных с помощью алгоритма Fernet.
    • SALT — случайная строка, добавляемая к паролю перед его хешированием.

    Важно! Когда контейнер запускается с указанием вышеописанных переменных окружений, то старые пароли и токены перестают работать. Необходимо в команде миграции БД Tasks указать переменные окружения, после чего необходимо запустить новый контейнер Tasks с указанием переменных окружения для возможности использования шифрования при создании новых объектов.

    См. подробную информацию в разделе "Дополнительная защита паролей и токенов" в руководстве администратора.

  • Добавлена группа параметров "FACE_QUALITY_DEFAULT_THRESHOLDS" сервиса Remote SDK, содержащая стандартные пороги для группы проверок "face_quality", политики "detect_policy", ресурсов "/handlers" и "/verifiers".

    В данной группе параметров есть два типа стандартных порогов:

    • пороги из поля "threshold", определяющие при каком значении LUNA PLATFORM будет считать, что проверка пройдена. Данные пороги аналогичны порогам в группе проверок "face_quality" в соответствующих запросах. Задание порогов в запросах переопределяет стандартные пороги, задаваемые в группе параметров "FACE_QUALITY_DEFAULT_THRESHOLDS".
    • пороги из поля "config", определяющие как интерпретировать ответ эстиматоров Natural Light, Fish Eye, Color Type и Red Eyes. Ранее данные пороги были недоступны.

    Пример настройки порогов для эстиматора Red Eyes:

    "red_eye": { "threshold": 0, "config": { "estimator": { "threshold": { "min": 0.5 } } } }

    Здесь:

    • поле "threshold" определяет значение "0" или "1", при котором LUNA PLATFORM будет считать, что проверка пройдена. Аналогично параметру "threshold" в запросах на выполнение "face_quality"
    • секция "config" > "estimator" > "threshold" определяет ответ эстиматора Red Eyes от "0" до "1".

  • Добавлена проверка доступности пользовательского Docker registry и базовых образов Lambda во время запуска сервиса.

  • Теперь не требуются никакие дополнительные права для выполнения запросов к ресурсу /lambdas/{lambda_id}/proxy сервиса Lambda.

Исправленные ошибки LP

  • Исправлена некорректная работа Cached Matcher с 64 версией нейронной сети для извлечения биометрических шаблонов лиц.

    Cached Matcher не кэшировал биометрические шаблоны 64 версии и выполнял сравнение используя данные из БД.

  • Исправлен некорректный формат поля "url" для лиц и атрибутов, генерируемый запросом "generate events".

    Например, адрес расположения лица мог возвращаться как 'url': 'http://127.0.0.1:5030/faces/359c8c12-b67d-4645-96dc-d8f1627f360f'.

    Правильный адрес: 'url': 'http://127.0.0.1:5030/3/faces/426542d6-5509-4e5b-8a01-e2abd5c0a8c6'

  • Запрос "stream events (beta)" теперь генерирует значение поля image_origin на основе детекции, если в теле запроса не указан параметр image_origin, но указан биометрический образец лица или тела.