Overrides

Thus far, we’ve defined config schemas, uploaded them to Miru, and stored configuration data in devices and tags. The next step is using overrides to render configuration data conforming to the config schema used by devices.

​

Override

An override references tag metadata to “override” the default configuration values of a config schema. Here is a hardware override example.

The default values in the config 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 config schema, only a subset of the config schema fields. However, it cannot specify fields not present in the config schema.

Overrides 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
• features.backflip: false

since the NVIDIA Jetson Orin Nano tag has

• supports_jump: true
• supports_spin: true
• supports_backflip: false

This would override the default values in the config schema, changing features.spin from false to true.

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

Combining tags with overrides provides a flexible method for rendering configuration data unique to each device that is assured to conform to a given config schema.