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

​
Override

An override references tag metadata that “overrides” the default configuration values of the 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 a concrete config for a client. The client’s tags determine the specific values referenced by overrides.

Combining tags with overrides provides a flexible method to evaluate configuration data unique to each client that’s formatted according to a given config schema.