Homework

Task 1: Multi-Dependency Chart with Conditional Subcharts

Goal: Build an application chart that declares three dependencies (PostgreSQL, Redis, and Memcached), uses conditions and tags to toggle them, and passes configuration through global values.

Instructions

1. Create a new chart called taskapp:

   helm create taskapp
   cd taskapp

2. Edit Chart.yaml to declare three dependencies:

   dependencies:
     - name: postgresql
       version: "13.x.x"       # use a valid version range
       repository: "https://charts.bitnami.com/bitnami"
       condition: postgresql.enabled
       tags:
         - database
     - name: redis
       version: "18.x.x"
       repository: "https://charts.bitnami.com/bitnami"
       condition: redis.enabled
       tags:
         - cache
     - name: memcached
       version: "7.x.x"
       repository: "https://charts.bitnami.com/bitnami"
       condition: memcached.enabled
       tags:
         - cache

   Replace the x.x portions with valid version numbers from the Bitnami repository.
3. In values.yaml, define global values and subchart overrides:

   global:
     storageClass: "standard"
     imageRegistry: ""
   
   postgresql:
     enabled: true
     auth:
       database: taskapp_db
       username: taskapp_user
   
   redis:
     enabled: true
     architecture: standalone
   
   memcached:
     enabled: false
   
   tags:
     database: true
     cache: true

4. Run helm dependency update and confirm tarballs appear in charts/.
5. Template the chart with memcached disabled and verify no Memcached resources appear:

   helm template taskapp . | grep -i memcached

6. Template again with memcached enabled via the command line:

   helm template taskapp . --set memcached.enabled=true | grep -i memcached

   Confirm Memcached resources now appear.
7. Template once more, disabling the entire cache tag group:

   helm template taskapp . --set tags.cache=false | grep -iE "redis|memcached"

   Confirm neither Redis nor Memcached resources appear.

Deliverable

Your Chart.yaml, values.yaml, and terminal output showing:

• Successful helm dependency update with three tarballs in charts/
• Memcached absent when disabled, present when enabled
• Both Redis and Memcached absent when tags.cache=false

Self-check

• ✓ All three dependencies are declared with valid version ranges in Chart.yaml
• ✓ Each dependency has both a condition and a tags entry
• ✓ helm dependency update succeeds and creates .tgz files in charts/
• ✓ condition overrides tags when both are set (memcached.enabled=true overrides tags.cache=false)
• ✓ Global values (global.storageClass) are accessible by subcharts

Task 2: OCI-Based Dependency and Version Pinning

Goal: Replace a traditional HTTPS repository dependency with an OCI registry reference, and explore version range semantics.

Instructions

1. Create a new chart called ociapp and declare a single dependency using the OCI protocol:

   dependencies:
     - name: redis
       version: "18.6.1"
       repository: "oci://registry-1.docker.io/bitnamicharts"

2. Run helm dependency build (note: build, not update, is required for OCI) and verify the tarball is pulled.
3. Now experiment with version ranges. Modify the version field using each of these range expressions one at a time, running helm dependency build after each change:
   • ">=18.0.0 <19.0.0" — any 18.x release
   • "~18.6.0" — patch-level updates only (18.6.x)
   • "^18.0.0" — minor and patch updates (18.x.x)
4. After each build, check which exact version was resolved:

   ls charts/
   cat Chart.lock

5. Document the resolved version for each range expression.

Deliverable

A summary table showing:

Range Expression	Resolved Version
"18.6.1" (exact)	(your result)
">=18.0.0 <19.0.0"	(your result)
"~18.6.0"	(your result)
"^18.0.0"	(your result)

Self-check

• ✓ The OCI repository URL uses oci:// protocol (no helm repo add needed)
• ✓ helm dependency build succeeds for OCI references
• ✓ You understand the difference between ~ (patch only) and ^ (minor + patch) ranges
• ✓ Chart.lock records the exact resolved version for each range

Task 3: Subchart Value Overrides and Global Propagation

Goal: Demonstrate mastery of the three mechanisms for passing values to subcharts: nested keys, import-values, and global.

Instructions

1. Using your taskapp chart from Task 1, create a ConfigMap template that reads both parent and global values:

   # templates/config.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: {{ .Release.Name }}-config
   data:
     DB_HOST: {{ .Release.Name }}-postgresql
     REDIS_HOST: {{ .Release.Name }}-redis-master
     STORAGE_CLASS: {{ .Values.global.storageClass }}
     ENVIRONMENT: {{ .Values.global.environment | default "development" }}

2. Add a new global value in values.yaml:

   global:
     storageClass: "standard"
     environment: "staging"

3. Override the PostgreSQL subchart password using the nested-key approach:

   helm template taskapp . \
     --set postgresql.auth.password=secretpass123 \
     --set global.environment=production

4. Inspect the rendered output and confirm:
   • The ConfigMap shows ENVIRONMENT: production (overridden from CLI)
   • The PostgreSQL Secret contains the password you specified
   • The PostgreSQL StatefulSet uses global.storageClass for its PVC
5. Finally, explore the import-values mechanism. Add an exports section to your dependency declaration:

   dependencies:
     - name: postgresql
       version: "13.x.x"
       repository: "https://charts.bitnami.com/bitnami"
       condition: postgresql.enabled
       import-values:
         - child: primary.service
           parent: dbService

   Template and confirm that .Values.dbService.ports.postgresql is populated from the subchart defaults.

Deliverable

Rendered template output showing:

• The ConfigMap with correct global value overrides
• Evidence that nested-key overrides reach the subchart
• Evidence that import-values pulls child values into the parent scope

Self-check

• ✓ Global values appear in both parent templates and subchart resources
• ✓ CLI --set overrides propagate through global and nested-key paths
• ✓ import-values successfully maps a child key into the parent value tree
• ✓ You can explain the precedence order: CLI > values file > subchart defaults