Target Configuration

This page describes the target configuration file used by Nomad to advertise local targets to the cluster, along with the available configuration parameters.

Structure

The target configuration file is a JSON file containing all the information required to describe and run one or more targets. It can define multiple targets, including several instances of the same type.

The file structure is as follows:

{
  "target_type": [
    {
      "target_uid": "target_type-XXXX-XXXX",
      "memory": {
        "storage": 1073741824,
        "ram": 1073741824
      },
      "engines": {
        "engine_type_1": {
          "version": "1.0.0",
          "image": "path/to/target/image_engine_type_1:tag",
          "supported_types": [
            "TYPE1",
            "TYPE2"
          ],
          "devices": [],
          "volumes": [],
          "env": {
            "MY_ENV_VAR": "value"
          },
          "auth": {
            "registry": "my.registry.gitlab.com",
            "username": "access_token_username",
            "password": "access_token_password"
          }
        },
        "engine_type_2": {
          ...
        }
      }
    },
    {
      "target_uid": "target_type-XXXX-XXXX",
      "engines": {
        ...
      }
    }
  ],
  "target_type_2": [
    ...
  ]
}

Parameters

Below is a detailed description of all available parameters in the target configuration file:

• target_type:
  A key representing a group of targets of the same type on the host. The value is a list of targets.
  This grouping is used to organize similar hardware (e.g., all Raspberry Pi 5 devices under rpi5).

  The target type must be consistent across the cluster. If a new type is introduced, it will be registered automatically when the first target of that type is added.

• target_uid:
  A unique identifier for the target within the cluster. This value is provided by the dAIEdge-VLab during target registration and is used for identification and scheduling.

• memory:
  Describes the memory resources available on the target. This information is used by the scheduler to allocate workloads appropriately. Values are expressed in bytes:

  • storage: Available persistent storage (used for models and benchmark results)
  • ram: Available system memory (used during execution)

• engines:
  A dictionary of inference engines available on the target. Each key represents an engine_type (e.g., tflite, onnx), and each engine is defined by the following fields:

  • version:
    Version of the inference engine.
    Limitation: Only one version per engine type can currently be defined per target.

  • image:
    Path to the Docker image used to run the inference engine.
    The image must be accessible from the dAIEdge-VLab environment. If it is private, authentication must be configured.

  • supported_types:
    List of benchmark types supported by the engine.
    These types are used to filter compatible benchmarks (e.g., TYPE1).
    See the Benchmark Types page for details.

  • devices:
    List of host devices to mount into the container (e.g., USB devices, serial ports).
    This is particularly useful for embedded or MCU-based targets requiring hardware interaction.

  • volumes:
    List of host directories to mount into the container.
    This enables access to local files from within benchmarking scripts.

  • env:
    Environment variables injected into the container at runtime.
    These are typically used to pass configuration data (e.g., IP address, credentials).

    These variables remain local to the host and are not exposed to the dAIEdge-VLab platform, ensuring sensitive data is not leaked.

  • auth: (optional)
    Authentication credentials for accessing private container images:

    • registry: Container registry URL (e.g., registry.gitlab.com)
    • username: Registry username or deploy token username
    • password: Registry password or deploy token password

    If the image is publicly accessible, this field can be omitted.

    For GitLab container registries, use credentials from a deploy token.
    These credentials are stored locally and are never exposed to the dAIEdge-VLab platform.

Environment Variables

Some environment variables can be defined in the env field of the engines section in the target configuration file to modify the behavior of the target scripts.

These variables are only available inside the container and are not exposed to the dAIEdge-VLab platform. They allow configuration data to be passed securely to the target scripts without leaking sensitive information.

Live Script Updates

If the Docker image does not contain the target scripts, you can use the following environment variables to dynamically fetch them from a repository.

This approach is useful during development, as it allows updating scripts without rebuilding the Docker image.

If $VERSION_TAG is not specified, the latest commit from the main branch is used.

Middleware Configuration

These environment variables are used to authenticate the target with the dAIEdge-VLab middleware.

They are required only if the target interacts with the middleware, primarily for trust, traceability, and security mechanisms (e.g., blockchain-based validation).

Untrusted targets are currently allowed but may be restricted in future versions.

These credentials can be found in the dAIEdge-VLab website.