​
Miru Agent

Deploying config instances to a robot involves a few major components: the config instances in the cloud, the Miru agent running on the robot, and the Miru SDK running within the target application on the robot. The Miru agent is a lightweight systemd service that pulls config instances defined in the cloud and exposes them to applications on the same machine over a Unix socket. The Miru agent is installed on a robot as a particular device. When the Miru SDK requests a config instance from the agent, the agent identifies the correct config instance to pull from the cloud using:
  1. The digest of the config schema
  2. The slug of the config type (defined at the root of the config schema)
  3. The device the agent is authenticated as
Simply provide the config schema file to the SDK. The config schema is then hashed to determine the digest, its config type slug is extracted (defined at the root of the schema), and the agent knows which device it is authenticated as. 
// instantiate the config instance from the agent
auto config_instance = miru::configs::ConfigInstance::from_agent(
    "/path/to/config-schema.yaml"
);
The agent retrieves the correct config instance from the cloud, caches it on the local file system, and returns it to the SDK for your application’s consumption. The agent can support multiple applications running on the same robot and is available to applications running inside containers by mounting the appropriate socket.

​
Rendering Configs

To ensure clarity as to how config instances are delivered to devices, a short example will suffice. Say we’re deploying the Motion Control config type to Robot A. The robot already has the Miru agent installed and running. A containerized application running on Robot A requests a config instance from the Miru SDK. The application provides the config schema file to the SDK, which was included in the application’s container image when the image was built. The config schema file contains the following: 
$miru_config_type_slug: "motion-control"
properties:
    # the config schema's contents
    ...
The SDK hashes the config schema’s contents to determine the digest. This digest and the motion-control config type slug are used to identify the v8 version of the Motion Control config type (commit 8f4d2e1) as the config schema the application adheres to. Config schema v8 is then rendered with the latest values from Robot A’s tags since the agent is authenticated as Robot A. The resulting config instance is returned to the agent, which then provides it to the SDK, which returns it to the containerized application for consumption. If Robot B made the same request with the same container image, the same config schema would be identified, but a different config instance would be returned since the agent on Robot B is authenticated as Robot B and Robot B’s tags differ from Robot A’s tags.

​
Networking & Caching

Devices are expected to have unstable internet connections. The Miru agent handles this by caching config instances on the filesystem. Thus, even if the network is offline, the agent continues to serve the latest cached config instance. Devices are also expected to lose power or be restarted suddenly. The agent handles these edge cases to continue serving config instances on reboot safely.

​
Conclusion

This concludes the core concepts guide, which walked through Miru’s core offering. We defined config schemas in a git repository, uploaded them to Miru, stored configuration data in devices and tags, defined overrides, and deployed a config instance to a device. To begin using Miru, continue to the getting started guide, where installation and usage are fully explained with examples to follow along.