​
Policy

Thus far, we’ve defined config schemas, uploaded them to Miru, and stored configuration data in clients and tags. The next step is using policies to format configuration data according to the config schema used by clients.

A policy is a set of overrides that hierarchically evaluate to a concrete config. Policies have two components:

  1. A policy schema
  2. A hierarchical set of overrides

When deploying a concrete config to a client, it must adhere to a particular config schema. Config schemas refer to a policy that evaluates the client’s tags to determine the unique concrete config for deployment.

As an example, the config schema v8 of the Motion Control config uses the v4 Policy.

​
Policy Schema

A policy schema defines the constraints on the output of a policy’s evaluation.

As with a config schema or a metadata schema, policy schemas are written in a configuration language like JSON Schema. Below is an example.

$schema: "https://json-schema.org/draft/2020-12/schema"
type: object
properties:
  mode:
    type: string
	default: "normal"
  maxSpeed:
    type: integer
    minimum: 1
    default: 1
  features:
    type: object
    properties:
      spin:
        type: boolean
        default: true
      jump:
        type: boolean
        default: false
      backflip:
        type: boolean
        default: false
    required: [spin, jump, backflip]
  accelerometer:
    type: object
    properties:
      id:
        type: string
      offsets:
        type: object
        properties:
          x:
            type: number
          y:
            type: number
          z:
            type: number
        required: [x, y, z]
      scaling_factor:
        type: object
        properties:
          x:
            type: number
          y:
            type: number
          z:
            type: number
        required: [x, y, z]
    required: [id, offsets, scaling_factor]
required: [device_id, speed, features, accelerometer]

Although config schemas and policy schemas interact with each other, they serve different purposes.

Config schemas refer to a policy for evaluating a concrete config for a client. Config schemas can only refer to a policy if the config schema is compatible with the policy’s schema. Thus, the policy schema constrains the output of a policy to ensure it is compatible with any config schemas using the policy.

​
Override

The second part of a policy is its overrides. An override references tag metadata that “overrides” the current evaluation of a policy. Here is a hardware override example.

The default values in the policy schema are shown on the left. On the right is the hardware override, which references the supports_jump, supports_spin, and supports_backflip fields in the metadata schema for the hardware tag type.

Overrides are completely named and defined by you. An override does not need to specify all the fields in a policy schema, only a subset of the policy schema fields. However, it cannot specify fields not present in the policy schema.

Policies can only be evaluated given a particular tag. For instance, the features.jump, features.spin, and features.backflip fields in the hardware override reference the supports_jump, supports_spin, and supports_backflip fields in the metadata schema for the hardware tag type.

Given the NVIDIA Jetson Orin Nano tag, the hardware override would use features.jump: true, features.spin: true, and features.backflip: false since the NVIDIA Jetson Orin Nano tag has supports_jump: true, supports_spin: true, and supports_backflip: false. This would override the default values in the policy schema, changing features.spin from false to true.

Overrides are hierarchically evaluated to determine a concrete config for a client. The client’s tags determine the specific values referenced by overrides.

By combining tags with overrides, policies grant a flexible method to evaluate configuration data unique to each client that’s formatted according to a given config schema