Stack and Services FAQ

How does inheritance work?

A child Stack may inherit service definitions, scripts, configuration, and properties from a parent Stack. Ambari loads the inherited content first and then applies explicit child overrides to form the final service model used by deployment plans. Override parent content only when platform, component-version, or compatibility requirements actually differ; keep common behavior in the parent so copied definitions do not drift across versions.

Which version is selected?

Stack selection identifies available service definitions, component versions, and compatible configuration. It is independent of selecting Ambari Server and Agent RPM versions, and a service-version change does not install or upgrade Ambari Metrics RPMs. A deployment or upgrade plan should record the Ambari, Stack, service, Metrics package, and monitoring-backend versions separately and validate that the candidate supports the combination.

What should a new Stack document?

At minimum, document services and components, cardinality, dependencies, configuration types and defaults, packages, lifecycle commands, custom actions, alerts, quick links, telemetry integration, and supported platforms. Keep public identifiers stable. For changes that can affect existing clusters, also document configuration migration, version selection, failure recovery, and rollback behavior.

How should changes be tested?

Test inheritance resolution, service-version selection, initial installation, start, stop, restart, upgrade, repeated execution, partial host failure, and recovery. In addition to loading the Stack metadata, inspect generated host-component assignments, packages, configuration, command arguments, request state, and service-check results. Preserve evidence for every platform claimed as supported.