Skip to content

LUNA PLATFORM v.5.64.0#

LP changes

  • The ability to set time to live (TTL) for objects in bucket (both local and S3) has been added.

    TTL for objects is calculated relative to the GMT time format.

    TTL for objects is set in days in the following ways:

    • During the creation of a bucket for all objects at once (basic TTL bucket policy).
    • After creating a bucket for specific objects using requests to the corresponding resources.

    The number of days is selected from the list in the corresponding requests (see below).

    In addition to the number of days, the parameter can take the value "-1", meaning that objects should be stored indefinitely.

    Configuring basic TTL bucket policy

    The basic TTL bucket policy can be configured in the following ways:

    • Using the --bucket-ttl flag for the lis_bucket_create.py script. For example, "python3 ./base_scripts/lis_bucket_create.py -ii --bucket-ttl=2".
    • Using a request to the Image Store service. For example, "curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-samples?ttl=2".

    Configuring TTL for specific objects

    TTL for specific objects can be configured using the "ttl" parameter in the following places:

    • In the "storage_policy" > "face_sample_policy", "body_sample_policy" and "image_origin_policy" handler policies.
    • In the requests "create object", "create images" and "save sample".

    If the "ttl" parameter is not specified, then the basic policy of the bucket in which the object is located (see above) will be applied.

    Supported cloud providers

    Amazon S3 cloud providers, Yandex cloud storage and MinIO are supported.

    Adding TTL to existing objects

    You can add a TLL to an existing object using PUT requests to the /objects, /images, /samples/{sample_type} resources of the Image Store service.

    You can add a TTL to an existing local bucket using a PUT request to the Image Store resource /buckets.

    To add a TTL for a bucket located in S3, you need to perform a migration using the "base_scripts/migrate_ttl_settings" script from the Image Store service. This is because for TTL objects in S3 is applied via tag related filters. The command to perform S3 bucket migration is given in the installation manual. See "Migration to apply TTL to objects in S3" for details on S3 bucket migration.

    Expiration of TTL

    When an object's TTL comes to an end, it is marked for deletion. For local buckets, the cleanup task is performed once a day (at 01:00 am). S3 buckets use internal ttl configuration rules.

    Note that there may be a delay between the expiration date and the date the item is actually deleted. Both for local storage and S3.

    Search for expiring objects

    To find out when an object expires, you can use queries with the HEAD methods on the /objects and /images resources. These requests return X-Luna-Expiry-Date response headers, which indicate the date on which the object is no longer eligible for persistence.

    See "TTL for objects" in the administrator manual for details.

  • Now Handlers service will send only one notification if a user has two callbacks with the same settings.

    If a user has created two callbacks that differ only in filters, the system will send a notification only once, even if the event satisfies both filters.

    For example, if two callbacks are configured to one third-party system with the only difference being that one callback has filters on passing Liveness and the other on reaching a certain level of "similarity", then when an event is generated that satisfies both filters, only one notification will be sent to the external system.

    This makes it easier to implement the logic of sending notifications when certain filters are met.

  • The ability to send notifications about the status of tasks and subtasks to Telegram has been added.

    Sending notifications to Telegram is implemented by adding a new type of callback telegram to the "notification_policy" of each task.

    To send notifications you should specify chat_id and token parameters.

    Sending notifications to Telegram can also be configured when creating a schedule for tasks.

  • In the containers of the Events and Licenses services, the Python version has been updated to 3.12.

    Support for older versions of Python has been discontinued.

  • The "video" > "orientation" > "angle" parameter has been added to the "video analytics (beta)" query parameters, which is responsible for the ability to rotate the video by 90, 180 or 270 degrees before processing it.

  • The ability to use a more secure algorithm to generate JWT tokens has been added.

    By default, Accounts service uses HS256 algorithm to sign JWT tokens. If necessary, you can use asymmetric cryptographic encryption using ES256 algorithm.

    For this purpose it is necessary to: - Generate ECDSA private key. - Encode the private key in Base64 format. - Set environment variables "ACCOUNTS_JWT_ECDSA_KEY" and "ACCOUNTS_JWT_ECDSA_KEY_PASSWORD".

    Important: Switching the signature algorithm from HS256 to ES256 (or vice versa) has a significant impact on token validation. All existing tokens signed with the previous algorithm will become invalid after the change. This is because the token signature verification mechanism expects the structure and cryptographic basis of the token to match the newly specified algorithm.

    See "JWT token algorithms" in the administrator manual.

  • The ability to encrypt passwords and tokens passed in the Estimator task and in the "notification_policy" policy has been added.

    To do this, pass custom values to FERNET_PASSPHRASE and SALT environment variables when starting the Tasks service container.

    • FERNET_PASSPHRASE — Password or key used to encrypt data using the Fernet algorithm.
    • SALT — Random string added to the password before it is hashed.

    Important: When the container is started with the above environment variables specified, the old passwords and tokens will no longer work. You must specify the environment variables in the Tasks database migration command, and then you must start a new Tasks container with the environment variables specified to be able to use encryption when creating new objects.

    See "Additional protection for passwords and tokens" in the administrator manual for details.

  • A section "FACE_QUALITY_DEFAULT_THRESHOLDS" of the Remote SDK service has been added, containing standard thresholds for the "face_quality" check group, "detect_policy", resources "/handlers" and "/verifiers".

    There are two types of standard thresholds in this section of parameters:

    • Thresholds from the "threshold" field, which determine at what value LUNA PLATFORM will consider the check to have passed. These thresholds are similar to the thresholds in the "face_quality" section of the corresponding requests. Setting thresholds in requests overrides the standard thresholds set in the "FACE_QUALITY_DEFAULT_THRESHOLDS" section.
    • Thresholds from the "config" field that determine how to interpret the response of Natural Light, Fish Eye, Color Type and Red Eyes estimators. Previously, these thresholds were not available.

    An example of configuring thresholds for a Red Eyes estimator:

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

    Here:

    • "threshold" field defines the value "0" or "1" at which LUNA PLATFORM will consider the check to have passed. Similar to the "threshold" parameter in "face_quality" requests.
    • "config" > "estimator" > "threshold" section defines the response of the Red Eyes estimator from "0" to "1".

  • Checking the availability of the custom Docker registry and Lambda base images during service startup has been added.

  • No additional permissions are now required to query the /lambdas/{lambda_id}/proxy resource of the Lambda service.

LP fixed errors

  • Fixed incorrect work of Cached Matcher with 64 version of neural network for face descriptors extraction.

    Cached Matcher did not cache descriptors of 64 version and performed matching using data from database.

  • Fixed incorrect format of the "url" field for faces and attributes generated by the "generate events" request.

    For example, the address of a face location could be returned as 'url': 'http://127.0.0.1:5030/faces/359c8c12-b67d-4645-96dc-d8f1627f360f'.

    Correct address: 'url': 'http://127.0.0.1:5030/3/faces/426542d6-5509-4e5b-8a01-e2abd5c0a8c6'

  • The "stream events (beta)" request now generates the value of the image_origin field based on detections if no image_origin parameter is specified in the body of the request, but a face or body sample is specified.