Flavors
What Are Flavors?
Garden Linux's flavor system solves a fundamental challenge: how to create dozens of specialized operating system images for different platforms, architectures, and use cases without creating a maintainability nightmare. At its core, a flavor is not a standalone definition, but a composition of smaller, reusable components called features.
Imagine needing to create images for:
- AWS, Azure, GCP, OpenStack, BareMetal ... platforms
- Each with amd64 and arm64 architectures
- Some with TPM2 and/or SecureBoot features
- Most for the Gardener/Kubernetes use case
- Some for different use cases
The combinatorial explosion of possibilities would be impossible to manage if each image variant required a complete, independent definition. The flavor system addresses this by separating concerns:
- Platform features - The deployment target (e.g.,
aws,azure,baremetal) - Element features - Functional components (e.g.,
gardener,cis) - Flag features - Lightweight modifiers (e.g.,
_prod,_fips,_usi)
This compositional approach allows Garden Linux to generate many unique flavor variants from the simple YAML definitions in flavors.yaml.
The Composition Philosophy
The flavor system embodies Garden Linux's customizable design philosophy. Instead of creating separate, hand-crafted images for each use case, we compose images from standardized building blocks.
Features are the primary building blocks of flavors. Each feature is a complete configuration unit that may include packages, configuration files, scripts, and dependencies on other features. Features combine through a directed acyclic graph (DAG) to form the complete image definition.
For a detailed explanation of feature types, the DAG resolution process, and the single-platform enforcement rule, see Features.
TIP
A complete list of features can be seen in the Features Reference.
TIP
For an explanation of how boot-related features interact, see Boot Modes and Secure Boot and Trusted Boot.
The Publication Pipeline
The flavor system not only defines what to build, but also manages the journey from development to production through the build/test/publish triad.
Selective Publication
Not all built flavors are published to end users. The publish flag in flavors.yaml controls distribution:
- features:
- gardener
- _prod
arch: amd64
build: true
test: true
test-platform: true
publish: trueThis separation enables several important workflows:
- Internal testing of new configurations before public release
- Restricted use of compliance images that have licensing constraints
- Gradual rollout of stable images to production
- Rapid iteration on experimental features without affecting users
TIP
More information can be looked up in the Flavors Configuration Reference
From Build to Publish
The publication pipeline follows a staged maturity model:
- Build: Create the image from feature components
- Test: Run validation suites across platforms (chroot, qemu, cloud)
- Publish: Distribute to public channels (S3, GHCR, GitHub)
Each stage acts as a gate. A flavor might have build: true but test: false during initial development. Once tests pass reliably, it can progress to test: true and eventually publish: true.
Naming and Identification
As flavors progress through the pipeline, each build is identified by a four-level naming hierarchy: cname (canonical name encoding just the feature set), flavor (cname plus architecture), versioned flavor (flavor plus version), and artifact base name (versioned flavor plus commit hash).
For the complete specification of this naming hierarchy including encoding rules and worked examples, see the canonical names section in the Flavors Reference.
Integration Points
The flavor system integrates with several other components in the Garden Linux ecosystem:
The gl-flavors-parse command-line tool parses flavors.yaml and generates filtered output matrices. For full command details and flags, see the Flavors Configuration Reference.