[FIX] Add Processing Engine protection for air-gapped Kubernetes deployments

[dburton-influxdata]

[FIX] Add Processing Engine protection for air-gapped Kubernetes deployments

Fixes #793

Summary

Adds automatic INFLUXDB3_UNSET_VARS to non-processor pods (ingester, querier, compactor) when processingEngine.enabled: false to prevent Processing Engine initialization failures in air-gapped Kubernetes environments.

Problem

InfluxDB 3 Enterprise has a binary bug (influxdata/influxdb_pro#3607) where Processing Engine initialization runs on ALL pods even when processingEngine.enabled: false. This causes critical failures in air-gapped deployments:

Serve command failed: Python environment initialization failed: Virtual environment error: 
Failed to initialize virtualenv: Activation script not found at '/plugins/.venv/bin/activate'

Impact

• Critical: Blocks all air-gapped Kubernetes deployments
• Affects: ingester, querier, compactor pods (all non-processor pods)
• Trigger: Pods cannot access internet to download Python packages

Solution

Official InfluxData Recommendation

Per official documentation:

⚠️ IMPORTANT: Setting plugin-dir="" or INFLUXDB3_PLUGIN_DIR="" (empty string) does not disable the Processing Engine. You must comment out, remove, or unset the configuration — not set it to empty.

The docs explicitly recommend using INFLUXDB3_UNSET_VARS for Docker/Kubernetes deployments:

docker run -e INFLUXDB3_UNSET_VARS="INFLUXDB3_PLUGIN_DIR" influxdb:3-enterprise

This PR Implementation

Automatically adds INFLUXDB3_UNSET_VARS to non-processor pods when Processing Engine is disabled:

{{- if not .Values.processingEngine.enabled }}
# Prevent Processing Engine initialization on non-processor pods (air-gapped deployments)
# Official docs: https://docs.influxdata.com/influxdb3/enterprise/reference/config-options/#disable-the-processing-engine
- name: INFLUXDB3_UNSET_VARS
  value: "INFLUXDB3_PLUGIN_DIR INFLUXDB3_PACKAGE_MANAGER INFLUXDB3_PLUGIN_REPO"
{{- end }}

Changes

Modified Files

• templates/ingester-statefulset.yaml - Add INFLUXDB3_UNSET_VARS to ingester pods
• templates/querier-statefulset.yaml - Add INFLUXDB3_UNSET_VARS to querier pods
• templates/compactor-statefulset.yaml - Add INFLUXDB3_UNSET_VARS to compactor pods

Behavior

• When processingEngine.enabled: false (default): Automatically unsets plugin variables on non-processor pods
• When processingEngine.enabled: true: No changes - processor pods continue working as expected
• User extraEnv: Preserved - users can still override via extraEnv if needed

Why This Fix Belongs in Helm Chart

Even after the binary bug is fixed in influxdb_pro:

1. Backward compatibility: Supports older binary versions with the bug
2. Defense in depth: Explicitly prevents Processing Engine on non-processor pods by design
3. Air-gap safety: Guarantees air-gapped deployments work regardless of binary version
4. Clear intent: Declaratively states "these pods should NEVER initialize Processing Engine"
5. Official best practice: Follows InfluxData's documented recommendation for disabling Processing Engine

Testing

Customer Validation

Customer confirmed workaround works:

"The work-around by unsetting the VARs seems to allow the Pods to start up now."

Test Scenarios

• ✅ Air-gapped deployment with processingEngine.enabled: false (default)
• ✅ Online deployment with processingEngine.enabled: true
• ✅ Mixed deployment (processor + non-processor nodes)
• ✅ User override via extraEnv

Related Issues

• Helm chart issue: Add Processing Engine protection for air-gapped Kubernetes deployments #793
• Binary bug: https://github.com/influxdata/influxdb_pro/issues/3607
• Customer workaround: https://github.com/influxdata/influxdb_pro/issues/3607#issuecomment-4453074298
• Official docs: https://docs.influxdata.com/influxdb3/enterprise/reference/config-options/#disable-the-processing-engine

Checklist

• Follows official InfluxData documentation recommendation
• Tested in air-gapped environment (customer validation)
• Backward compatible (no breaking changes)
• Documentation links added to template comments
• Applies only when processingEngine.enabled: false
• Preserves user extraEnv overrides
• No impact on processor pods

---

Priority: HIGH
Risk: Minimal (follows official docs, tested workaround, backward compatible)
Impact: Critical fix for air-gapped deployments