Skip to content

fix(opentelemetry-demo): wait for flagd before starting shipping - #2384

Open
dpacheconr wants to merge 1 commit into
open-telemetry:mainfrom
dpacheconr:fix-shipping-flagd-wait-init-container
Open

fix(opentelemetry-demo): wait for flagd before starting shipping#2384
dpacheconr wants to merge 1 commit into
open-telemetry:mainfrom
dpacheconr:fix-shipping-flagd-wait-init-container

Conversation

@dpacheconr

@dpacheconr dpacheconr commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Description

shipping crash-loops on a fresh install or rollout because there is no
ordering guarantee between the shipping and flagd deployments — if
shipping starts before flagd's port is up, it panics and restarts
until flagd happens to be ready.

open-telemetry/opentelemetry-demo#3875 attempted to fix this in
application code (falling back to open_feature::NoOpProvider when
FlagdProvider::new fails at startup), but that approach was pushed back
on in review. This PR fixes it at the chart level instead: a
wait-for-flagd initContainer on shipping, using the exact same
pattern the chart already uses for cart (wait-for-valkey-cart) and
other components (wait-for-kafka) — no application code changes needed.

Bumped the chart to 0.41.1 (patch, additive/non-breaking) and
regenerated the example manifests via make generate-examples CHARTS=opentelemetry-demo.

Link to tracking issue

Related to open-telemetry/opentelemetry-demo#3845, alternative approach to open-telemetry/opentelemetry-demo#3875

Authorship

  • I, a human, wrote this pull request description myself.

shipping crash-loops on a fresh install or rollout because there is
no ordering guarantee between the shipping and flagd deployments.
Add a wait-for-flagd initContainer, matching the existing
wait-for-kafka / wait-for-valkey-cart pattern already used by other
components in this chart, so shipping blocks until flagd:8013 is
reachable instead of crashing.

Assisted-by: Claude Sonnet 5
@dpacheconr
dpacheconr requested review from a team and julianocosta89 as code owners September 3, 2026 08:39
dpacheconr added a commit to dpacheconr/opentelemetry-demo that referenced this pull request Sep 3, 2026
Comment the wait-for-flagd initContainer as a workaround, pointing at
open-telemetry/opentelemetry-helm-charts#2384 so it's removed once the
upstream chart handles this itself.

Assisted-by: Claude Sonnet 5
dpacheconr added a commit to newrelic/opentelemetry-demo that referenced this pull request Sep 3, 2026
* fix(newrelic/k8s): wait for flagd before starting shipping

shipping crash-loops on install/rollout since there's no ordering
guarantee between the shipping and flagd deployments. Add a
wait-for-flagd initContainer (busybox nc, same pattern as the
chart's existing wait-for-kafka/wait-for-valkey-cart containers)
so shipping blocks until flagd:8013 is reachable instead of
crashing.

Tested locally in minikube: scaled flagd to 0 replicas, restarted
shipping — it now sits at Init:0/1 with 0 restarts until flagd
comes back, then starts cleanly.

Assisted-by: Claude Sonnet 5

* docs(newrelic/k8s): note upstream fix for shipping/flagd wait

Comment the wait-for-flagd initContainer as a workaround, pointing at
open-telemetry/opentelemetry-helm-charts#2384 so it's removed once the
upstream chart handles this itself.

Assisted-by: Claude Sonnet 5

@julianocosta89 julianocosta89 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants