Skip to main content
Framed content
A config instance, also known as a config or an instance, is a set of parameters used to modify the behavior of code. Config instances are stored as JSON files, which applications parse into a structured format for consumption.

​
Properties

​
target status
enum
The desired state of the config instance, inherited from its owner deployment.Visit the deployment’s target status for more information.Allowed values:
  • staged
  • deployed
  • removed
​
activity status
string
The last known activity state of the config instance, inherited from its owner deployment.Visit the deployment’s activity status for more information.Allowed values:
  • staged
  • needs_review
  • queued
  • deployed
  • removing
  • archived
​
error status
string
The last known error state of the config instance, inherited from its owner deployment.Visit the deployment’s error status for more information.Allowed values:
  • none
  • failed
  • retrying
​
status
string
This property merges the activity status and error status fields, with error states taking precedence over activity states when errors are present.Below are examples of status values for different activities and error states.
Activity StatusError StatusStatus
stagednonestaged
deployednonedeployed
queuedretryingretrying
removedfailedfailed
Enum: staged, needs_review, queued, deployed, removing, archived, failed, retrying
​
content
object
The configuration values that are deployed to the device in the format of a JSON object.
​
file path
string
The file path the config instance is deployed to relative to the /srv/miru/config_instances directory.A file path of /v1/motion-control.json deploys the config instance to /srv/miru/config_instances/v1/motion-control.json.Examples: /v1/motion-control.json, /safety.json
​
parent
Config Instance
The config instance that this config instance was patched from.Examples: CFG-Cpa13
​
config schema
Config Schema
The config schema that the config instance must adhere to.Example: SCH-FmoDN
​
device
Device
The device to which the config instance is deployed.Examples: Sojourner, Johnny Test, Robot 11
​
origin
Deployment
The deployment with which the config instance was created.Visit the origin section for more information.Example: DPL-123
​
owner
Deployment
The deployment that a config instance currently belongs to.Visit the owner section for more information.Example: DPL-123

​
File formats

Currently, config instances only support JSON. However, support for more formats, including YAML and JSON-C, is coming soon!

​
Owners and origins

Config instances are created and used as part of a deployment. Each config instance has two key deployment relationships:
  • Origin - the deployment with which the config instance was created
  • Owner - the deployment that a config instance currently belongs to
These concepts are best explained via example. Initial Deployment Let’s say our application has three config types: Mobility, Perception, and Safety. We create an initial deployment, DPL-MT3Ec. The deployment contains config instances CFG-K9xF6, CFG-BrM1v, and CFG-9ai6A which are instantiations of Mobility, Perception, and Safety respectively. Since all configs are brand new, all three config instances’ owners and origins are DPL-MT3Ec.
InstanceOwnerOrigin
CFG-K9xF6 (Mobility)DPL-MT3EcDPL-MT3Ec
CFG-BrM1v (Perception)DPL-MT3EcDPL-MT3Ec
CFG-9ai6A (Safety)DPL-MT3EcDPL-MT3Ec
Mobility Edit After our initial deployment, we decided to make an edit to the Mobility config instance, creating DPL-8Xerr to replace DPL-MT3Ec. Since no edits were made to the Perception or Safety instances, DPL-8Xerr reuses the Perception and Safety configs from DPL-MT3Ec. As such, the total number of config instances only increases from three to four.
InstanceOwnerOrigin
CFG-K9xF6 (Mobility)DPL-MT3EcDPL-MT3Ec
CFG-BrM1v (Perception)DPL-8XerrDPL-MT3Ec
CFG-9ai6A (Safety)DPL-8XerrDPL-MT3Ec
CFG-6jrCj (Mobility)DPL-8XerrDPL-8Xerr
The new Mobility config instance, CFG-6jrCj, has an owner and origin of DPL-8Xerr since it was created with that deployment. The old Mobility config instance is removed and retains its owner as DPL-MT3Ec. Finally, since DPL-8Xerr reuses the Perception and Safety instances from DPL-MT3Ec, CFG-BrM1v and CFG-9ai6A have their ownership transferred to DPL-8Xerr. Safety Edit Some more time passes, and we need to make another edit. This time we edit the Safety config instance, creating DPL-8jVBY to replace DPL-8Xerr. Since no edits were made to the Mobility or Perception instances, DPL-8jVBY reuses the config instances from DPL-8Xerr for those config types. The total number of config instances thus increases from four to five.
InstanceOwnerOrigin
CFG-K9xF6 (Mobility)DPL-MT3EcDPL-MT3Ec
CFG-BrM1v (Perception)DPL-8XerrDPL-MT3Ec
CFG-9ai6A (Safety)DPL-8jVBYDPL-MT3Ec
CFG-6jrCj (Mobility)DPL-8jVBYDPL-8Xerr
CFG-2kQ1b (Safety)DPL-8jVBYDPL-8jVBY
The new Safety config instance, CFG-2kQ1b, has an owner and origin of DPL-8jVBY since it was created with that deployment. The old Safety config instance is removed and retains its owner as DPL-8Xerr. Finally, the other two config instances have their ownership transferred to DPL-8jVBY. Conclusion Owners and origins help maintain an accurate record of a device’s configuration changes. Instead of unnecessarily creating new config instances for every config type on each edit, new instances are only created when the config type is edited. Origins and owners make it easy to track the initial deployment that created the config instance, as well as the current deployment that the config instance belongs to.