Resource Manager

Introduction

The Resource Manager is the Service Manager (SM) module responsible for tracking and providing information about host resources available on a Node. It reads a JSON configuration file describing the Node's resources — devices, filesystem mounts, host entries, environment variables, and group memberships — and makes this information available to other SM modules during service instance setup.

The Resource Manager does not enforce quotas or limits itself. Instead, it serves as a resource information provider: the Launcher's container runtime queries it when setting up an instance's OCI runtime configuration, and the SM client reports the resource list to CM during registration so the cloud can make informed scheduling decisions.

Role Within the Service Manager

The Resource Manager connects two key flows:

1. Instance setup — when the container runtime starts a service instance, it looks up each resource declared in the service's item configuration and applies the corresponding devices, mounts, groups, environment variables, and host entries to the OCI runtime spec
2. Node registration — when SM registers with CM, it reports all available resources (name and shared count) so CM's scheduler can verify that a Node has the required resources before placing a service there

┌─────────────────────────────────────────────────────────────┐
│                     Service Manager                          │
│                                                             │
│  ┌──────────────────────┐     ┌──────────────────────────┐ │
│  │   Resource Manager   │     │       SM Client          │ │
│  │                      │     │                          │ │
│  │  • Parses JSON file  │────▶│  Reports resources to CM │ │
│  │  • Stores resources  │     │  (name + sharedCount)    │ │
│  │  • Provides lookups  │     └──────────────────────────┘ │
│  └──────────┬───────────┘                                   │
│             │                                               │
│             │ GetResourceInfo(name)                          │
│             ▼                                               │
│  ┌──────────────────────────────────────────────────────┐   │
│  │              Container Runtime (Launcher)             │   │
│  │                                                      │   │
│  │  Applies to OCI spec:                                │   │
│  │  • Devices (with permissions)                        │   │
│  │  • Filesystem mounts                                 │   │
│  │  • Group IDs                                         │   │
│  │  • Environment variables                             │   │
│  │  • Host entries (/etc/hosts)                         │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Interface

The Resource Manager implements the ResourceInfoProviderItf interface with two methods:

Method	Purpose
GetResourcesInfos	Returns all available resources (name and shared count) — used by SM client for Node registration
GetResourceInfo	Returns full resource details by name — used by the container runtime during instance setup

Configuration

The Resource Manager is configured with a single parameter: the path to a JSON file describing the Node's available resources.

{
  "resourceInfoFilePath": "/etc/aos/resources.json"
}

If the file does not exist at startup, the Resource Manager initializes successfully with an empty resource list. This allows Nodes without special hardware resources to operate normally.

Resource Definition Format

The resource information file is a JSON array where each entry describes one named resource available on the Node:

[
  {
    "name": "gpu0",
    "sharedCount": 2,
    "groups": ["video", "render"],
    "mounts": [
      {
        "destination": "/dev/dri",
        "type": "bind",
        "source": "/dev/dri",
        "options": ["rbind", "rw"]
      }
    ],
    "envs": ["GPU_DEVICE=/dev/dri/renderD128"],
    "hosts": [
      {
        "hostname": "gpu-host",
        "ip": "192.168.1.100"
      }
    ],
    "devices": [
      "/dev/dri/card0:/dev/dri/card0:rwm",
      "/dev/dri/renderD128:/dev/dri/renderD128:rw"
    ]
  },
  {
    "name": "serial0",
    "sharedCount": 1,
    "devices": ["/dev/ttyUSB0:/dev/ttyUSB0:rw"]
  }
]

Resource Fields

Field	Type	Required	Description
name	string	Yes	Unique identifier for this resource — referenced by service item configurations
sharedCount	integer	No (default: 0)	Maximum number of service instances that can use this resource concurrently
groups	string[]	No	Linux group names — the container process is added to these groups for device access
mounts	object[]	No	Filesystem mounts added to the container's OCI spec
envs	string[]	No	Environment variables injected into the container (format: KEY=VALUE)
hosts	object[]	No	Host entries added to the container's /etc/hosts file
devices	string[]	No	Host devices exposed to the container (format: host_path:container_path:permissions)

Mount Object

Field	Type	Description
destination	string	Mount point path inside the container
type	string	Filesystem type (e.g., bind, tmpfs, devtmpfs)
source	string	Source path on the host
options	string[]	Mount options (e.g., rbind, ro, rw, nosuid)

Device Format

Devices are specified as colon-separated strings with up to three parts:

<host_path>:<container_path>:<permissions>

• host_path — device path on the host (supports wildcard expansion for device directories)
• container_path — device path inside the container (optional — defaults to same as host path)
• permissions — OCI device access permissions: r (read), w (write), m (mknod), or combinations like rwm

Shared Resource Counting

The sharedCount field controls how many service instances can concurrently use a resource. This is enforced at the scheduling level by CM, not by the Resource Manager itself:

1. SM reports each resource's sharedCount to CM during Node registration
2. When CM schedules a service that requires a resource, it decrements the available count for that resource on the target Node
3. If the available count reaches zero, CM will not schedule additional instances requiring that resource on that Node

A sharedCount of 0 means the resource has no concurrency limit — any number of instances can use it simultaneously.

How Resources Are Applied to Containers

When the container runtime starts a service instance, it processes the instance's item configuration which lists required resources by name. For each resource:

1. Group resolution — each group name is resolved to a GID via the system's group database, and the GID is added to the container process's supplementary groups
2. Mount injection — each mount entry is added to the OCI runtime spec's mounts array
3. Environment variables — each environment variable string is added to the container process's environment
4. Device exposure — each device string is parsed, host devices are enumerated (supporting directory wildcards), and OCI LinuxDevice entries are created with the specified permissions
5. Host entries — host entries from resources are merged into the container's network hosts configuration

This process runs after the base OCI spec is generated from the service image and before the container is started.

Integration With Cloud Scheduling

The resource information flows through the system in two directions:

Upward (SM → CM → Cloud)

During SM registration, the SM client calls GetResourcesInfos and includes the resource list in the SMInfo message sent to CM. Each resource is reported as a ResourceInfo protobuf message containing only the name and shared_count fields. This tells the cloud what resources are available on each Node.

Downward (Cloud → CM → SM)

When the cloud creates a service configuration, it can specify required resources in the item configuration's resources array. Each entry contains a resource name and access mode (permissions). During scheduling, CM verifies the target Node has the required resources with available shared capacity before placing the instance.

Error Handling

Condition	Behavior
Resource file not found	Initialization succeeds with empty resource list — logged as warning
Invalid JSON format	Initialization fails with parse error
Resource not found by name	GetResourceInfo returns eNotFound error — the container runtime propagates this as an instance start failure
Group name not found on system	Container setup fails — the instance cannot start without the required group

When a resource lookup fails during instance startup, the container runtime reports the failure as a ResourceAllocateAlert to CM, which forwards it to the cloud for operator visibility.

Related Pages

• Service Manager — SM overview and subcomponent summary
• Launcher — how the Launcher uses resource information during instance setup
• Image Manager — service image management including item configurations that reference resources
• Network Manager — per-service networking (complementary to resource-based device/mount setup)

• Scheduling and Placement — how CM uses resource availability for scheduling decisions

• Storage and Quotas — storage quota configuration (related to resource limits)