Environment Variables

The secondary (standby) cluster uses LogScale-specific GCP_RECOVER_FROM_* environment variables to coordinate failover recovery. These are injected into the HumioCluster pod spec as extraEnvVars by Terraform when var.dr == "standby".

Environment Variable Reference
Variable Type Purpose Source
GCP_RECOVER_FROM_BUCKET Plain value Primary GCS bucket name to recover snapshot from local.final_gcp_recover_from_bucket
GCP_RECOVER_FROM_WORKLOAD_IDENTITY Plain value Always "true" โ€” use Workload Identity for cross-region auth Hardcoded
GCP_RECOVER_FROM_REPLACE_REGION Plain value Region to replace in bucket paths during recovery local.final_gcp_recover_from_replace_region
GCP_RECOVER_FROM_REPLACE_BUCKET Plain value Bucket name mapping <primary-bucket>/<secondary-bucket> Computed from bucket names
GCP_RECOVER_FROM_ENCRYPTION_KEY secretKeyRef Encryption key from primary cluster for reading encrypted data Secret: dr-secondary-gcs-storage-encryption

Note: GCP_RECOVER_FROM_REGION is not used โ€” LogScale ignores it for GCS because GCS bucket access is not region-scoped the way S3 is. The region parameter is simply not evaluated during GCS recovery.

Note: ALLOW_KAFKA_RESET_UNTIL_TIMESTAMP_MS is not required when GCP_RECOVER_FROM_BUCKET is set. LogScale automatically enables allowKafkaReset when bucketStorageRecoverFrom is configured โ€” this is built-in behaviour that does not require a separate variable.

Naming Convention

All DR recovery environment variables follow the pattern GCP_RECOVER_FROM_<component>:

  • GCP_RECOVER_FROM_ prefix identifies GCS recovery-related variables

  • <component> identifies the specific recovery parameter (BUCKET, ENCRYPTION_KEY, etc.)

These variables are consumed by LogScale at startup and map to the internal bucketStorageRecoverFrom configuration, which controls where the recovery snapshot is loaded from.

Important Notes

  • Recovery environment variables are injected when var.dr != "" (both "standby" and "active" modes) to prevent pod recreation during promotion

  • Variable values are populated during Terraform deployment via locals and module outputs

  • The encryption key is passed via secretKeyRef to avoid exposing it in the pod spec

  • Changes to recovery variables require terraform apply on the standby workspace

  • The GCP_RECOVER_FROM_REPLACE_BUCKET is computed as <primary-bucket>/<secondary-bucket> format

Environment Variable Preservation

The GCP_RECOVER_FROM_* environment variables are intentionally preserved when promoting from dr="standby" to dr="active". The condition var.dr != "" ensures env vars remain in the pod spec across both DR modes.

Why env vars are preserved

The humio-operator calculates a hash of the pod spec (including environment variables) to determine if pods need to be recreated. If env vars were removed during promotion:

  • Pod spec hash would change

  • Operator would delete and recreate all pods

  • Ephemeral PVCs would be deleted (data loss)

  • Recovered snapshot data would be lost

Why this is safe

The GCP_RECOVER_FROM_* env vars are only read once at startup by DataSnapshotLoader:

  • After successful recovery, the local snapshot has a valid Kafka epoch

  • Subsequent pod restarts use the local snapshot, NOT the recovery bucket

  • The primary bucket is marked readOnly=true in cluster state

  • Env vars are harmlessly ignored after initial recovery

Note: If you need to remove these env vars later (e.g., after the original primary is decommissioned), do so in a maintenance window when brief pod recreation is acceptable. This pattern is consistent with the OCI DR implementation.

Resources Destroyed During Promotion

When promoting from dr="standby" to dr="active", some resources are destroyed and recreated:

Resource Why Impact
HumioCluster nodePools null to full nodePool spec Operator reconciles and creates pods
DR failover Cloud Function No longer needed on active cluster Function, Pub/Sub, alert policy removed
Cloud Monitoring Alert Policy Failover automation no longer needed Alert deleted