Homework

Complete these tasks before the next lesson. They reinforce hook and test concepts and push you to handle failure scenarios.

Goal: Create a post-upgrade hook that simulates sending a deployment notification.

In your hookdemo chart (or a new chart), create a file templates/hooks/notify.yaml.
The hook should be a Job that:
- Runs on the post-upgrade event
- Has a hook weight of 10
- Uses the hook-succeeded delete policy
- Runs a busybox container that prints: Notification: Release <release-name> upgraded successfully at <timestamp>
Install the chart, then upgrade it (change any value).
Verify the notification hook ran by checking logs, then confirm it was deleted (because of hook-succeeded policy).

The YAML file for notify.yaml and terminal output showing:

The notification message in the Job logs
The Job no longer existing after successful completion (kubectl get jobs should not list it)

✓ The hook is annotated with helm.sh/hook: post-upgrade
✓ The hook weight is 10
✓ The Job is automatically deleted after success (verify with kubectl get jobs)
✓ The notification message includes the release name (use {{ .Release.Name }} in the template)

Goal: Understand what happens when a pre-upgrade hook fails.

Create a pre-upgrade hook Job that deliberately fails (exit code 1):

containers:
  - name: fail-check
    image: busybox:1.36
    command: ["sh", "-c", "echo 'Validation failed!' && exit 1"]

A short write-up (100–200 words) answering:

What error message did Helm display when the hook failed?
Did the Deployment replica count change to 3, or did it remain at the previous value?
What was the release status after the failed upgrade? (Use helm status hookdemo)
Why is this behaviour useful for database migrations?

Goal: Build a test suite with three ordered test pods that validate different aspects of the release.

Create three test pod templates in templates/tests/:
- test-dns.yaml (weight -10): Resolves the service DNS name using nslookup
- test-http.yaml (weight 0): Makes an HTTP request to the service health endpoint using wget --spider
- test-response.yaml (weight 10): Fetches the response body and checks it contains expected content using wget -qO- | grep
All three should use before-hook-creation delete policy.
Install or upgrade the chart, then run helm test hookdemo --logs.
Verify all three tests pass and execute in the correct order.

The three test YAML files and the helm test output showing all three phases as Succeeded.

✓ You have exactly three test templates
✓ Hook weights enforce the order: DNS (-10) then HTTP (0) then response content (10)
✓ All three tests pass with Phase: Succeeded
✓ Each test validates a different layer (DNS, connectivity, content)

Grading Rubric

Criterion	Excellent	Satisfactory	Needs Work
Hook annotations	All three annotations (hook, weight, delete-policy) used correctly in every hook	Hook and delete-policy present; weight missing or default	Missing annotations or incorrect event types
Execution ordering	Weights produce the intended execution order and this is verified via timestamps or logs	Weights are set but order not explicitly verified	No weight ordering attempted
Failure handling	Clearly explains that failed pre-hooks abort the release and describes the safety benefit	Observes the abort but explanation is vague	Did not test a failing hook
Test suite	Three distinct tests covering DNS, HTTP, and content; all pass; order verified	Two tests present and passing	Only one test or tests do not pass
Delete policies	Demonstrates both `before-hook-creation` and `hook-succeeded` with evidence of cleanup	Uses one policy correctly	No delete policy set; stale resources left behind

There is no formal submission for this course. These tasks are for your own development. However:

Keep your hook and test YAML files — you will extend them in future lessons.
If you are working with a group or mentor, share your Task 2 write-up for discussion.
Ensure all three tasks are complete before the next lesson.

Next lesson: Lesson 16 — continuing your Helm journey.