Values Files | Validated Patterns

Exploring values

A value represents a specific configuration or parameter that influences the behavior of a validated pattern. These values may range from simple settings like port numbers to more complex elements such as host names and DNS entries. Their role is to ensure that validated patterns adapt to diverse needs and scenarios, whether they involve straightforward settings or more complex configurations. Values are instrumental in ensuring the efficient and seamless operation of validated patterns.

Benefits of using values files

Values files offer a flexible and modular approach to deploying validated patterns, providing key advantages:

Adaptability: Empowers adjustment of validated patterns or applications to diverse deployment scenarios without direct modifications to the underlying codebase.
Maintainability: Streamlines the process of updating and managing configurations, promoting maintainability and reducing the likelihood of errors during deployment.

Integration of values files in validated patterns

Validated patterns use values files to dynamically adapt to different deployment scenarios. During deployment, the pattern references the values file to fetch specific configurations, making the deployment process versatile and adaptable.

Example of a value in a values file

applications:
  coffeeshop-test:
    name: quarkuscoffeeshop-demo
    namespace: quarkuscoffeeshop-demo
    project: quarkuscoffeeshop-demo
    path: charts/store/quarkuscoffeeshop-charts
    overrides:
      - name: projectnamespace
        value: quarkuscoffeeshop-demo
      - name: Release.release-namespace
        value: quarkuscoffeeshop-demo
      - name: storeid
        value: TEST

In this example, the coffeeshop-test application has specific overrides, such as setting the projectnamespace to quarkuscoffeeshop-demo, the Release.release-namespace to quarkuscoffeeshop-demo, and the storeid to TEST. These values can be easily adjusted based on the desired configuration for the application, showcasing the flexibility provided by values files in tailoring deployments to specific requirements.

Outline of a basic values file

In a values file, each variable declares an element with a default value, influencing Helm templates and guiding validated patterns. As files or overrides enter the rendering pipeline, they replace default values in the values files, following the principle that the last value takes precedence for adaptability.

The three-fold distinction in validated patterns, "Global," "Main," and "ClusterGroup," practically applies the Helm override scheme. While "main" and "global" terms are used interchangeably, Helm differentiates by allowing "global" variables to extend to sub-charts, ensuring comprehensive configuration access. Values files, structured in free-form YAML, provide flexibility for any YAML variable type and are organized into Global, Main, and ClusterGroup configurations.

In Validated patterns, values files follow Helm rules, but the "global" and "ClusterGroup" sections have distinct meanings within this framework.

Increasingly, more value files are designed solely for overriding base chart values. These files may not always have "ClusterGroup," "Main," or "Global" values. The decision to include these sections depends on the specific overrides required for each case.

Key sections of values files:

Global: Global values refer to configuration settings shared across multiple charts within a deployment. These values are distributed among various charts to avoid redundancy and configuration setting repetition, promoting consistency. Each pattern includes a values-global.yaml file, which contains configurations that are automatically incorporated into the application specification processed by the GitOps operator.
ClusterGroup: The ClusterGroup holds a specific significance within validated patterns. It defines clusters that are anticipated to share nearly identical configurations, serving a common architectural purpose. A ClusterGroup may consist of one or many members. Conventionally, there is a main ClusterGroup defined in main.clusterGroupName in values-global.yaml, acting as the hub or starting point for each pattern. Additional ClusterGroups can be managed by the main ClusterGroup through tools like Red Hat Advanced Cluster Management (RHACM).

Not all value files contain a ClusterGroup section; instead values-global sets the starting point, and these value files can subsequently define managed clusters.