Skip to main content
Version: 3.1.0 (Preview)

How to Define Stacks and Services

Service Definition

Define a service in metainfo.xml. Give it a unique name and version, list its components, and provide Python 3 lifecycle scripts. Components use categories such as MASTER, SLAVE, and CLIENT; cardinality expresses the allowed placement count.

Declare commandScript, customCommands, requiredServices, configuration-dependencies, osSpecifics, and generated configFiles as needed. Configuration dependencies tell Ambari which configuration types a component requires and which changes can require a restart. Package scripts and templates must render the files consumed by the service.

Services may define alerts.json, quicklinks/quicklinks.json, themes, and a service advisor. The service metrics.json describes metrics retained by Ambari's control plane. Current BIGTOP services additionally use telemetry.json and telemetry profiles for the Prometheus/VictoriaMetrics monitoring path; these are separate contracts.

Stack Definition

Define a stack version with its descriptor, services, repositories, configuration, and supported upgrade metadata. Verify inheritance and the fully assembled service definitions. Current examples are BIGTOP HDFS and BIGTOP VictoriaMetrics.

Validation

Run descriptor validation, package and configuration rendering, service checks, custom actions, advisor validation, and upgrade tests on the target stack. Check that every referenced script, package, configuration type, repository, and telemetry profile exists. Keep the target operating system and architecture explicit; a source profile alone is not a production certification.