⏲ Add initContainers to jobs to wait for dependencies instead of crashing (demos)

Open
#208 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
kubernetes

Research direction

Start with demos/demos-v2.yaml and review the listed demos, using the linked nifi-kafka-druid-water-level-data serviceaccount.yaml and setup-superset.yaml as the reference. Check each applicable demo's Kubernetes manifests for dependency waits, namespace-scoped RBAC, and attached ServiceAccounts. Done means applicable demo pods wait for dependencies instead of showing premature CrashLoopBackOff failures.

Written by the indexing model from the issue text.

Description

release-retro/25.3.0

[!NOTE]
This came out of the 25.3.0 Release Retro

Many demos have (Job or other) pods showing CrashLoopBackoff until their dependencies are satisfied.

This causes confusion when launching demos, especially during demo testing.

Each stack/demo should make use of initContainers to wait for dependencies to be satisfied without giving false failure indications.

[!TIP]

List of demos

List generation command
cat demos/demos-v2.yaml | yq -yr '.demos | keys' | sed 's/^-/- [ ]/'
  • airflow-scheduled-job
  • data-lakehouse-iceberg-trino-spark
  • end-to-end-security
  • hbase-hdfs-load-cycling-data
  • jupyterhub-keycloak
  • jupyterhub-pyspark-hdfs-anomaly-detection-taxi-data
  • logging
  • nifi-kafka-druid-earthquake-data
  • nifi-kafka-druid-water-level-data
  • signal-processing
  • spark-k8s-anomaly-detection-taxi-data
  • trino-iceberg
  • trino-taxi-data

[!WARNING]
It is possible that some stacks also need the same treatment, but most of the waiting can be done in the actual demo.

Dominant language
Jupyter Notebook
Stars
3
Forks
13
Avg merge
2d 20h
Merged PRs (30d)
2

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stackabletech/demos

All issues in stackabletech/demos

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.