Features
A feature is a named bundle of processing capability on a HEAT environment. It groups the runners that do the work with the node templates that workflows call. Think of it as an optional module that can be installed, updated or switched off at the platform level. Open Platform, then Features, or reach it under Configuration (/admin/configuration/features).
A feature is not a platform setting. Platform settings are key-value configuration under Configuration. A feature bundles capability.
The platform features
A standard install registers a set of platform features.
| Feature | Provides |
|---|---|
| HEAT System Nodes | The built-in steps every install needs, hosted inside the platform. Always on |
| Core Utils | General data transforms for CSV, JSON and protobuf |
| Dashboard Tools | Steps that build dashboard-ready outputs |
| Audio Utils | Audio processing steps |
| Video Utils | Video processing steps |
Project companion features appear on the same page, delivered for one project or customer and registered the same way. The developer pages describe each platform runner, for example core-utils and dashboard-tools.
Enabling and disabling
Each feature has a switch. When a feature is enabled, its node templates are available to session templates and its runners can be scheduled. When it is disabled, its node templates and runners are treated as unavailable for new work, and sessions whose templates use those steps will not progress past them. Nothing is deleted, and historical results stay where they are.
Disable features you do not use. Fewer active features means fewer runner pods to provision and fewer errors from steps whose prerequisite data never arrives.
HEAT System Nodes cannot be disabled. Every install depends on it.
Registering a feature with a manifest
A .heat manifest is a JSON file that registers a feature, its runner images and its node templates in one step. Upload it here. The page validates the manifest before you apply it, reporting whether it is valid, whether it creates a new feature or updates an existing one, and how many runner types and node templates it touches. Confirm to apply.
The container images the manifest names must already be available to the cluster, for example in your registry or air-gapped mirror. The manifest only points at an image reference the cluster can pull.
Registration is an upsert. A feature that is not yet present is created. One that already exists is updated, matching runners and node templates by name. Node templates that already exist keep their names, so session templates that reference them keep working. A changed configuration schema or a new runner image can still affect sessions in flight, so plan a manifest update like any other production change.
Building a runner and writing its manifest is developer work. See Building your own runner.
Related
- Feature and node template concepts
- Runners
- Building your own runner
- Configuration