Skip to content

v.5.139.0#

Changes

  • A new Builder service has been added, providing Docker image build functionality.

    The Docker image building process, previously part of the Lambda service, is now a separate service — Builder. This allows for control and management of the build process, reducing the impact of potential failures on the core LUNA PLATFORM services.

    Key features of the Builder service:

    • Asynchronous task queue: the service accepts build tasks and processes them sequentially, ensuring stability under load.
    • Building Docker images and sending them to the Docker Registry.
    • Ability to track task status and obtain build logs.

    Use case:

    1. The user sends a request to create a lambda via the API.
    2. Instead of building it manually, the Lambda service sends a request with the archive and image parameters to the Builder service.
    3. The Builder queues the task, executes the build, and uploads the completed Docker image to the registry.
    4. Lambda receives a successful build status and a link to the completed image from the Builder, after which it can run the lambda.

    Key changes:

    1. A Helm chart for the Builder service has been added to the distribution. The Launch Lambda documentation section has been updated.

    2. Builder service settings have been added. Note: Analogs to existing Lambda service settings have been moved to the Builder configuration where possible. Please note the following:

    3. LUNA_BUILDER_REGISTRY and LUNA_BUILDER_INSECURE_REGISTRIES — the address of the Docker Registry where Builder will send built images (similar to LAMBDA_REGISTRY and LAMBDA_INSECURE_REGISTRIES).

    4. LUNA_BUILDER_S3 — settings for accessing the bucket where lambda code archives are stored.

    5. LUNA_BUILDER_REDIS_DB_ADDRESS — Redis address, including username and password, if Redis is protected.

    6. The LUNA_LAMBDA_BUILD_LIMITS parameter group has been moved to the Builder service and is now called LUNA_BUILDER_BUILD_LIMITS. This means that when updating LUNA PLATFORM, previously configured values ​​are automatically migrated to the new parameter group.

    7. New parameter groups for interaction with the Builder service have been added to the Lambda service: LUNA_BUILDER_ADDRESS and LUNA_BUILDER_TIMEOUTS.

    Note: The Docker image build process can take a long time. If necessary, increase the timeout values ​​in LUNA_BUILDER_HTTP_SETTINGS.

    For more information, see Builder service and Builder service configuration.

  • The ability to set Time To Live (TTL) for objects at the folder level has been added.

    You can now manage object retention periods not only at the bucket and individual file level, but also at the folder level. This allows for flexible data storage control at all levels.

    Key changes:

    • TTL for folders: when creating or modifying a folder, you can specify ttl parameter (in days). This value becomes the default TTL for all objects stored in this folder unless they have their own ttl.
    • By default, the current TTL policy of the source object or folder is preserved during copying. You can override the TTL in the copy request if necessary.
    • The TTL of an object is determined by priority: the TTL of the object is applied first, then the folder, and only then the bucket.

    For more information about TTL and folder operations, see Object TTL, /images and /objects resources.

  • Tools for diagnosing problems when processing a stream or video file have been added to the Video Agent service container: ffmpeg, ffprobe and luna_decoder.

    Added tools allow you to determine whether the issue is related to unavailable video sources, format incompatibility, connection instability, or other factors hindering processing. The resulting data will help you better understand the situation and speed up the debugging process.

    A detailed guide, step-by-step instructions, and descriptions of all parameters are available in the new section Stream troubleshooting.

  • The required field availability.available has been added to the responses of the get analytic and get analytics requests.

    The available value (true/false) indicates whether at least one agent capable of processing this analytics is currently registered in the system. This field reflects only the presence of a suitable agent in the system, not free slots for processing new tasks. This allows you to determine which analytics are potentially available for use.

  • Now, if the max_stream_count parameter (a positive integer) is set in the user_config of a lambda of the Agent type, it will override the max_active_streams parameter, which determines the maximum number of streams for a single lambda instance.

    See create lambda, put lambda, import lambda and update lambda config.

Fixed errors

  • Fixed behavior that caused an internal server error (status code 500) when executing the import lambda request with incorrectly filled data in the JSON of any of the request parts: credentials, parameters, or deploy_parameters.

    Now in such cases, error 42017 is returned with the description "Failed to parse multipart payload for lambda import" and status code 400.

  • The parameter names in the people count analytics have been corrected: people_count_lte and people_count_gte have been replaced with people_count__lte and people_count__gte, respectively (with double underscores). Validation of these parameters has also been corrected.