wu-sheng opened a new pull request, #190: URL: https://github.com/apache/skywalking-helm/pull/190
## Problem The OAP init job is a `post-install,post-upgrade,post-rollback` Helm hook. Under the very common `helm upgrade --install --wait`, this **deadlocks**: - Helm waits for **all release resources** to become `Ready` before it runs `post-*` hooks. - The OAP `Deployment` runs in `-Dmode=no-init` and, when the storage schema is missing, blocks in OAP's `ModelInstaller` loop (`"... is running in 'no-init' mode, waiting ... retry 3s later"`) — its `12800` port never opens, so the readiness probe never passes. - The schema is created by the init job… which is a `post-*` hook that Helm won't run until the Deployment is `Ready`. Result: the Deployment never becomes Ready → the hook never runs → the schema is never created → `helm` times out. This bites new users on a fresh install / fresh storage. Hooks fundamentally cannot solve this when storage is an embedded subchart: a `pre-*` hook init job cannot reach main-phase storage (the storage service does not exist yet), and a `post-*` hook deadlocks under `--wait`. Schema init must run in the **same phase as storage**. ## Fix - **Remove the hook annotations** so the init job runs as a normal main-phase resource, alongside storage and the OAP Deployment. OAP no-init self-blocks until the job creates the schema, so `--wait` resolves instead of deadlocking. Correct ordering comes from OAP's runtime behavior, not Helm phase ordering, so the single-run (one pod) `Job` semantics are unchanged. - **Hash-suffixed Job name** (`...-oap-init-<8-char hash of .Values>`). A Job's `spec.template` is immutable, so a stable name would make `helm upgrade` fail with `field is immutable` whenever the pod template changes. Hashing yields a fresh Job on any relevant change and Helm prunes the previous one — which also addresses the long-standing "Job already exists, cannot rerun" pain. - **`oapInit.ttlSecondsAfterFinished`** (new, optional, default empty) to auto-clean finished Jobs via the K8s TTL-after-finished controller. Left off by default so GitOps tools (Argo CD/Flux) don't recreate the Job after deletion. - **OAP startupProbe** default `failureThreshold` raised `9 → 30` (90s → 300s) so the pod waits for the init job during a cold start instead of being restarted. ## Notes - Under bare `--wait`, Helm does not wait for the (now normal) Job — it waits on the Deployment, which self-converges once the Job creates the schema. Add `--wait-for-jobs` to have Helm surface init-job failures directly. Documented in the README. - The README "Rerun OAP init job" section is simplified: upgrades that change a value re-run init automatically; to force a rerun, delete the Job and `helm upgrade` (Helm recreates it). ## Validation - `helm lint` clean; `helm template` renders for elasticsearch (embedded ECK), external ES, postgresql, and banyandb. - Init Job renders as a plain `Job` (no hook annotations) with a hash name that is deterministic across runs and changes when values change. - `ttlSecondsAfterFinished` omitted by default, renders when set. - No e2e test or CI workflow depends on the hook / `--wait`, so the change is transparent to e2e. ## Docs kept in sync `chart/skywalking/values.yaml`, `chart/skywalking/README.md`, and root `README.md`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
