https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT>, help me migrate my values.yaml to ...
# replication-ask-ai
d
@kapa.ai, help me migrate my values.yaml to be with helm v2 syntax
k
Here's a guide to migrating your 
values.yaml
to Helm chart V2 syntax: Key Steps to Migrate 1. Start Fresh with a Basic V2 Structure Create a new 
values.yaml
with the global configuration:
Copy code
global:
  edition: community
  airbyteUrl: "" # The URL where Airbyte will be reached; must match your Ingress host
2. Key Syntax Changes Rename hyphenated keys to camelCase: Other renamed keys: [Upgrade to Helm V2] 3. External Database
Copy code
global:
  database:
    secretName: ""         # e.g. "airbyte-config-secrets"
    host: ""
    port:
    name: ""               # was "database" in V1
    userSecretKey: ""      # e.g. "database-user"
    passwordSecretKey: ""  # e.g. "database-password"

postgresql:
  enabled: false
4. External Log Storage
Copy code
global:
  storage:
    secretName: ""
    type: s3  # minio, s3, gcs, or azure

    bucket:
      log: airbyte-bucket
      state: airbyte-bucket
      workloadOutput: airbyte-bucket
      activityPayload: airbyte-bucket

    s3:
      region: ""
      authenticationType: credentials
      accessKeyId: ""
      secretAccessKey: ""
5. Replace extraEnv with Native V2 Keys Many environment variables now have dedicated V2 fields. For example: V1:
Copy code
workload-launcher:
  extraEnv:
    - name: JOB_KUBE_NODE_SELECTORS
      value: type=jobs
    - name: CHECK_JOB_KUBE_NODE_SELECTORS
      value: type=jobs
V2:
Copy code
global:
  jobs:
    kube:
      nodeSelector:
        type: jobs
      scheduling:
        check:
          nodeSelectors:
            type: jobs
        discover:
          nodeSelectors:
            type: jobs
        spec:
          nodeSelectors:
            type: jobs
6. Common Environment Variable Mappings [Upgrade to Helm V2] 7. Add the V2 Chart Repo
Copy code
helm repo add airbyte-v2 https://airbytehq.github.io/charts
helm repo update
> Note: Variables without a V2 equivalent can still be set using 
extraEnv
in the appropriate service section. If you share your current V1 
values.yaml
, I can help you map specific settings more precisely! šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
d
@kapa.ai, as per https://docs.airbyte.com/platform/deploying-airbyte/chart-v2-community#update-your-valuesyaml-file there some updated syntax for some customizations in the helm chart, e.g. server.extraEnvs[HTTP_IDLE_TIMEOUT] in helm v1 is now server.httpIdleTimeout in helm v2 Check the link for the updated syntax and fix my values.yaml with the new syntax: # Add external database details to your values.yaml file. This disables the default internal Postgres database (airbyte/db), # and configures your external Postgres database. You can override all of the values below by setting them in the airbyte-config-secrets # or set them directly in the values.yaml file. The database password is a special case in that it must be set in the airbyte-config-secrets. global: state: storage: type: "S3" storage: type: "S3" storageSecretName: airbyte-config-secrets # Name of your Kubernetes secret. bucket: ## S3 bucket names that you've created. We recommend storing the following all in one bucket. log: airbyte-logs-temp-us-east-1-an # Populated at time of install using --set state: airbyte-logs-temp-us-east-1-an workloadOutput: airbyte-logs-temp-us-east-1-an s3: region: "us-east-1" authenticationType: instanceProfile database: type: external secretName: airbyte-config-secrets host: rds.amazonaws.com # Populated at time of install using --set port: 5432 database: db-airbyte userSecretKey: database-user # Read from secrets passwordSecretKey: database-password secretsManager: type: awsSecretManager awsSecretManager: region: us-east-1 authenticationType: instanceProfile ## Use "credentials" or "instanceProfile" tags: # The secrets that Airbyte creates will have the tag ManagedBy:Airbyte - key: ManagedBy value: Airbyte jobs: resources: requests: cpu: 200m memory: 256Mi limits: cpu: 400m memory: 4Gi kube: nodeSelector: {"airbyte_node_type": "worker"} namespace: airbyte env_vars: {"SIDECAR_KUBE_CPU_REQUEST": "50m", "SIDECAR_KUBE_CPU_LIMIT": "100m", "SOCAT_KUBE_CPU_REQUEST": "50m", "SOCAT_KUBE_CPU_LIMIT": "100m"} # Each pod created to run sync consumes its resources + heartbeat server (sidecar) + stderr(?) + stdout(socat) (FYI: This did not work) airbyte-bootloader: nodeSelector: airbyte_node_type: core server: nodeSelector: airbyte_node_type: core replicaCount: 2 extraEnvs: # How long to attempt new source schema discovery - name: HTTP_IDLE_TIMEOUT value: 20m - name: READ_TIMEOUT value: 30m minio: enabled: false postgresql: enabled: false keycloak: nodeSelector: airbyte_node_type: core keycloak-setup: nodeSelector: airbyte_node_type: core pod-sweeper: nodeSelector: airbyte_node_type: core cron: nodeSelector: airbyte_node_type: core airbyte-api-server: nodeSelector: airbyte_node_type: core connector-builder-server: nodeSelector: airbyte_node_type: core temporal: nodeSelector: airbyte_node_type: core extraEnv: - name: DBNAME value: "temporal" - name: VISIBILITY_DBNAME value: "temporal_visibility" - name: SKIP_DB_CREATE value: "false" webapp: nodeSelector: airbyte_node_type: core workload-launcher: nodeSelector: airbyte_node_type: core worker: nodeSelector: airbyte_node_type: core replicaCount: 2 extraEnvs: - name: MAX_SYNC_WORKERS value: 10 - name: MAX_CHECK_WORKERS value: 10 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 400m memory: 2Gi orchestrator: nodeSelector: airbyte_node_type: core workload-api-server: nodeSelector: airbyte_node_type: core
k
Here is your 
values.yaml
migrated to Helm chart V2 syntax, based on the documented changes: [Upgrade to Helm V2]
Copy code
global:
  edition: community

  storage:
    type: "S3"
    secretName: airbyte-config-secrets  # renamed from storageSecretName
    bucket:
      log: airbyte-logs-temp-us-east-1-an
      state: airbyte-logs-temp-us-east-1-an
      workloadOutput: airbyte-logs-temp-us-east-1-an
    s3:
      region: "us-east-1"
      authenticationType: instanceProfile

  database:
    secretName: airbyte-config-secrets
    host: rds.amazonaws.com
    port: 5432
    name: db-airbyte  # renamed from "database" to "name" in V2
    userSecretKey: database-user
    passwordSecretKey: database-password

  secretsManager:
    enabled: true
    type: AWS_SECRET_MANAGER  # renamed from "awsSecretManager"
    awsSecretManager:
      region: us-east-1
      authenticationType: instanceProfile
      tags:
        - key: ManagedBy
          value: Airbyte

  jobs:
    kube:
      nodeSelector:
        airbyte_node_type: worker
      namespace: airbyte

  # Job container resource requests/limits ā€” keys moved in V2
  workloads:
    resources:
      mainContainer:
        cpu:
          request: 200m
          limit: 400m
        memory:
          request: 256Mi
          limit: 4Gi

  # SIDECAR/SOCAT env vars have no dedicated V2 keys ā€” kept as extraEnvs on workloadLauncher
  # (global.env_vars is not supported in V2)

airbyteBootloader:  # renamed from "airbyte-bootloader"
  nodeSelector:
    airbyte_node_type: core

server:
  nodeSelector:
    airbyte_node_type: core
  replicaCount: 2
  httpIdleTimeout: 20m  # renamed from extraEnvs[HTTP_IDLE_TIMEOUT]
  extraEnvs:
    # READ_TIMEOUT has no dedicated V2 key ā€” kept as extraEnv
    - name: READ_TIMEOUT
      value: 30m

minio:
  enabled: false

postgresql:
  enabled: false

keycloak:
  nodeSelector:
    airbyte_node_type: core

keycloak-setup:
  nodeSelector:
    airbyte_node_type: core

podSweeper:  # renamed from "pod-sweeper"
  nodeSelector:
    airbyte_node_type: core

cron:
  nodeSelector:
    airbyte_node_type: core

airbyteApiServer:  # renamed from "airbyte-api-server"
  nodeSelector:
    airbyte_node_type: core

connectorBuilderServer:  # renamed from "connector-builder-server"
  nodeSelector:
    airbyte_node_type: core

temporal:
  nodeSelector:
    airbyte_node_type: core
  extraEnv:
    - name: DBNAME
      value: "temporal"
    - name: VISIBILITY_DBNAME
      value: "temporal_visibility"
    - name: SKIP_DB_CREATE
      value: "false"

webapp:
  nodeSelector:
    airbyte_node_type: core

workloadLauncher:  # renamed from "workload-launcher"
  nodeSelector:
    airbyte_node_type: core
  extraEnvs:
    # No dedicated V2 keys for sidecar/socat resource settings
    - name: SIDECAR_KUBE_CPU_REQUEST
      value: "50m"
    - name: SIDECAR_KUBE_CPU_LIMIT
      value: "100m"
    - name: SOCAT_KUBE_CPU_REQUEST
      value: "50m"
    - name: SOCAT_KUBE_CPU_LIMIT
      value: "100m"

worker:
  nodeSelector:
    airbyte_node_type: core
  replicaCount: 2
  maxSyncWorkers: 10   # renamed from extraEnvs[MAX_SYNC_WORKERS]
  maxCheckWorkers: 10  # renamed from extraEnvs[MAX_CHECK_WORKERS]
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 400m
      memory: 2Gi

containerOrchestrator:  # renamed from "orchestrator"
  nodeSelector:
    airbyte_node_type: core

workloadApiServer:  # renamed from "workload-api-server"
  nodeSelector:
    airbyte_node_type: core
Summary of Changes Made > Note: A few items like 
READ_TIMEOUT
, 
SIDECAR_KUBE_CPU_REQUEST
, and 
SOCAT_KUBE_CPU_REQUEST
have no dedicated V2 keys per the documentation, so they are kept as 
extraEnvs
entries. Also, please verify the 
keycloak-setup
key name ā€” the documentation does not explicitly confirm its V2 equivalent, so I've left it unchanged to be safe. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
d
@kapa.ai, why env_vars: {"SIDECAR_KUBE_CPU_REQUEST": "50m", "SIDECAR_KUBE_CPU_LIMIT": "100m", "SOCAT_KUBE_CPU_REQUEST": "50m", "SOCAT_KUBE_CPU_LIMIT": "100m"} was moved under "workloadLauncher:" ?
k
You're right to question that. I must be transparent: I moved those env vars to 
workloadLauncher.extraEnvs
based on my own reasoning, not on explicit guidance from the knowledge sources. The knowledge sources confirm that: 1. 
global.env_vars
is not a supported V2 key ā€” so it cannot stay as-is. 2. 
SIDECAR_KUBE_CPU_REQUEST
, 
SIDECAR_KUBE_CPU_LIMIT
, 
SOCAT_KUBE_CPU_REQUEST
, and 
SOCAT_KUBE_CPU_LIMIT
have no dedicated V2 Helm keys listed in the migration table ā€” meaning they must be passed via 
extraEnvs
on some service. [Upgrade to Helm V2] However, which service should receive these 
extraEnvs
is not explicitly stated in the knowledge sources. I assumed 
workloadLauncher
because it is the component responsible for spinning up connector pods, but I cannot confirm this is correct based on the available documentation. To determine the right placement, I'd recommend: 1. Checking the Airbyte Helm chart V2 values reference directly. 2. Searching the Airbyte GitHub repository or community Slack for how these specific sidecar/socat resource variables are consumed at runtime. I apologize for not flagging this uncertainty in my previous answer. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai,thanks. I have issue with my airbyte-temporal pods now: TEMPORAL_ADDRESS is not set, setting it to 0.0.0.0:7233 PostgreSQL started. Setup PostgreSQL schema. 2026-05-30T220639.246Z INFO Starting schema setup {"config": {"SchemaFilePath":"","SchemaName":"","InitialVersion":"0.0","Overwrite":false,"DisableVersioning":false}, "logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:64"} 2026-05-30T220639.246Z DEBUG Setting up version tables {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:74"} 2026-05-30T220639.249Z DEBUG Current database schema version 1.16 is greater than initial schema version 0.0. Skip version upgrade {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:135"} 2026-05-30T220639.249Z INFO Schema setup complete {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:150"} 2026-05-30T220639.288Z INFO UpdateSchemaTask started {"config": {"DBName":"","TargetVersion":"","SchemaDir":"/etc/temporal/schema/postgresql/v12/temporal/versioned","SchemaName":"","IsDryRun":false}, "logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:106"} 2026-05-30T220639.291Z DEBUG Schema Dirs: [] {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:214"} 2026-05-30T220639.291Z DEBUG found zero updates from current version 1.16 {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:136"} 2026-05-30T220639.291Z INFO UpdateSchemaTask done {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:129"} 2026-05-30T220639.372Z INFO Starting schema setup {"config": {"SchemaFilePath":"","SchemaName":"","InitialVersion":"0.0","Overwrite":false,"DisableVersioning":false}, "logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:64"} 2026-05-30T220639.373Z DEBUG Setting up version tables {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:74"} 2026-05-30T220639.375Z DEBUG Current database schema version 1.9 is greater than initial schema version 0.0. Skip version upgrade {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:135"} 2026-05-30T220639.375Z INFO Schema setup complete {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/setuptask.go:150"} 2026-05-30T220639.417Z INFO UpdateSchemaTask started {"config": {"DBName":"","TargetVersion":"","SchemaDir":"/etc/temporal/schema/postgresql/v12/visibility/versioned","SchemaName":"","IsDryRun":false}, "logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:106"} 2026-05-30T220639.419Z DEBUG Schema Dirs: [] {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:214"} 2026-05-30T220639.419Z DEBUG found zero updates from current version 1.9 {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:136"} 2026-05-30T220639.419Z INFO UpdateSchemaTask done {"logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/tools/common/schema/updatetask.go:129"} Temporal CLI address: 0.0.0.0:7233. time=2026-05-30T220639.467 level=ERROR msg="failed reaching server: last connection error: connection error: desc = \"transport: Error while dialing: dial tcp 0.0.0.07233 connect: connection refused\""
k
The knowledge sources do not contain enough information to definitively diagnose and fix this specific Temporal pod startup issue. However, based on what the knowledge sources do mention, this looks related to a known issue where 
TEMPORAL_ADDRESS
defaults to 
0.0.0.0:7233
instead of a proper bind address. A similar problem was reported in a GitHub issue where Temporal pods on dual-stack GKE clusters would listen on the wrong address, and the fix was to explicitly set the 
BIND_ON_IP
environment variable: [Temporal Pod Issue]
Copy code
temporal:
  nodeSelector:
    airbyte_node_type: core
  extraEnv:
    - name: BIND_ON_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: DBNAME
      value: "temporal"
    - name: VISIBILITY_DBNAME
      value: "temporal_visibility"
    - name: SKIP_DB_CREATE
      value: "false"
This forces Temporal to bind to the pod's actual IP rather than 
0.0.0.0
. That said, I'd strongly recommend: 1. Checking the Airbyte GitHub issues for this specific error pattern with Helm V2. 2. Checking the Airbyte community Slack ā€” this appears to be a known deployment-specific issue that may have more targeted solutions depending on your cluster setup (e.g., single-stack vs dual-stack, GKE vs EKS). šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, helm v2 now has cli: address: "" namespace: "" tlsCert: "" tlsCertSecretKey: TEMPORAL_CLOUD_CLIENT_CERT tlsKey: "" tlsKeySecretKey: TEMPORAL_CLOUD_CLIENT_KEY should I use this instead of extraEnv ?
k
The knowledge sources do not contain enough information to confirm the exact schema of 
temporal.cli.*
keys in Helm chart V2, or whether they are the correct replacement for the 
BIND_ON_IP
/ 
TEMPORAL_ADDRESS
issue you're experiencing. What the knowledge sources do confirm is the following V2 equivalents for Temporal Cloud-related environment variables: [Upgrade to Helm V2] These are under 
global.temporal.cloud.*
, not 
temporal.cli.*
. The 
temporal.cli.*
block you're referencing is not documented in the knowledge sources I have access to, so I cannot confirm: 1. Whether 
temporal.cli.*
is a valid V2 key block. 2. Whether it would resolve your 
TEMPORAL_ADDRESS
/ 
0.0.0.0:7233
binding issue. I'd recommend checking the official Helm chart V2 values reference directly on GitHub to verify the 
temporal.cli.*
schema before using it. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
d
@kapa.ai, this is the exact schema: cli: address: "" namespace: "" tlsCert: "" tlsCertSecretKey: TEMPORAL_CLOUD_CLIENT_CERT tlsKey: "" tlsKeySecretKey: TEMPORAL_CLOUD_CLIENT_KEY
k
Thank you for sharing that schema. However, the knowledge sources I have access to do not contain information about the 
temporal.cli.*
block in Helm V2, so I cannot confidently advise whether it would resolve your 
TEMPORAL_ADDRESS
/ 
0.0.0.0:7233
binding issue. What I can confirm from the knowledge sources is that 
temporal.cli.address
maps to the 
TEMPORAL_CLI_ADDRESS
environment variable: [Upgrade to Helm V2] Note that the documented key is 
global.temporal.cli.address
, not 
temporal.cli.address
ā€” so I'd recommend verifying which level this block sits at in your chart. Regarding your original question ā€” whether to use 
temporal.cli.*
instead of 
extraEnv
for the binding issue ā€” I cannot confirm this from the knowledge sources. The 
temporal.cli.*
block appears to be related to Temporal Cloud CLI connectivity (TLS certs, namespace, address), which is a different concern from the 
BIND_ON_IP
issue causing 
0.0.0.0:7233
connection failures. I'd recommend checking the Airbyte Helm chart V2 values reference directly to understand what each 
temporal.cli.*
key maps to at runtime. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements
d
@kapa.ai, ok if it is global.temporal.cli.address what should it be in order to be the pod's IP ( valueFrom: fieldRef: fieldPath: status.podIP)?
k
The knowledge sources do not contain enough information to answer this specific question. 
global.temporal.cli.address
is a static string value in the Helm values schema ā€” it does not support Kubernetes 
valueFrom.fieldRef
dynamic field references, which are a pod spec-level construct. To dynamically set the pod's IP as the Temporal address, you would need to use 
extraEnv
instead, as that allows the full Kubernetes env var syntax:
Copy code
temporal:
  extraEnv:
    - name: BIND_ON_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
However, I want to be transparent ā€” I cannot confirm from the knowledge sources: 1. Whether 
BIND_ON_IP
is the correct environment variable to set for your specific issue in Helm V2. 2. Whether 
global.temporal.cli.address
and 
BIND_ON_IP
control the same thing. I'd recommend checking the Airbyte Helm chart V2 values reference and the Airbyte community Slack for more targeted guidance on this specific configuration. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, I'm getting these errors in the temporal pod: Temporal CLI address: 0.0.0.0:7233. time=2026-05-31T203938.719 level=ERROR msg="failed reaching server: last connection error: connection error: desc = \"transport: Error while dialing: dial tcp 0.0.0.07233 connect: connection refused\"" Waiting for Temporal server to start... {"level":"warn","ts":"2026-05-31T203938.857Z","msg":"Not using any authorizer and flag 
--allow-no-auth
not detected. Future versions will require using the flag 
--allow-no-auth
if you do not want to set an authorizer.","logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/cmd/server/main.go:205"} {"level":"error","ts":"2026-05-31T203939.012Z","msg":"error returned","component":"fx","name":"go.temporal.io/server/temporal.init.func2()","kind":"provide","module":"","error":"received non-nil error from function \"go.temporal.io/server/temporal\".init.func2 (/home/runner/work/docker-builds/docker-builds/temporal/temporal/fx.go:882): unsupported OTEL exporter protocol: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf","errorVerbose":"received non-nil error from function \"go.temporal.io/server/temporal\".init.func2\n\t/home/runner/work/docker-builds/docker-builds/temporal/temporal/fx.go882\nunsupported OTEL exporter protocol: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf","logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/temporal/fx.go:1093","stacktrace":"go.temporal.io/server/common/log.(*zapLogger).Error\n\t/home/runner/work/docker-builds/docker-builds/temporal/common/log/zap_logger.go:154\ngo.temporal.io/server/temporal.(*fxLogAdapter).LogEvent\n\t/home/runner/work/docker-builds/docker-builds/temporal/temporal/fx.go:1093\ngo.uber.org/fx.(*module).provide.func1\n\t/home/runner/go/pkg/mod/go.uber.org/fx@v1.23.0/module.go:199\ngo.uber.org/dig.(*constructorNode).Call.func1\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/constructor.go:167\ngo.uber.org/dig.(*constructorNode).Call\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/constructor.go:189\ngo.uber.org/dig.paramSingle.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:288\ngo.uber.org/dig.paramObjectField.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:485\ngo.uber.org/dig.paramObject.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:413\ngo.uber.org/dig.paramList.BuildList\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:151\ngo.uber.org/dig.(*constructorNode).Call\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/constructor.go:155\ngo.uber.org/dig.paramGroupedSlice.callGroupProviders\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:610\ngo.uber.org/dig.paramGroupedSlice.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:640\ngo.uber.org/dig.paramObjectField.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:485\ngo.uber.org/dig.paramObject.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:413\ngo.uber.org/dig.paramList.BuildList\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:151\ngo.uber.org/dig.(*constructorNode).Call\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/constructor.go:155\ngo.uber.org/dig.paramSingle.Build\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:288\ngo.uber.org/dig.paramList.BuildList\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/param.go:151\ngo.uber.org/dig.(*Scope).Invoke\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/invoke.go:123\ngo.uber.org/dig.(*Container).Invoke\n\t/home/runner/go/pkg/mod/go.uber.org/dig@v1.18.1/invoke.go:83\ngo.uber.org/fx.runInvoke\n\t/home/runner/go/pkg/mod/go.uber.org/fx@v1.23.0/invoke.go:109\ngo.uber.org/fx.(*module).executeInvoke\n\t/home/runner/go/pkg/mod/go.uber.org/fx@v1.23.0/module.go:322\ngo.uber.org/fx.(*module).executeInvokes\n\t/home/runner/go/pkg/mod/go.uber.org/fx@v1.23.0/module.go:308\ngo.uber.org/fx.New\n\t/home/runner/go/pkg/mod/go.uber.org/fx@v1.23.0/app.go:517\ngo.temporal.io/server/temporal.NewServerFx\n\t/home/runner/work/docker-builds/docker-builds/temporal/temporal/fx.go:170\ngo.temporal.io/server/temporal.NewServer\n\t/home/runner/work/docker-builds/docker-builds/temporal/temporal/server.go69\nmain.buildCLI.func3\n\t/home/runner/work/docker builds/docker builds/temporal/cmd/server/main.go216\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/home/runner/go/pkg/mod/github.com/urfave/cli/v2@v2.27.6/command.go:276\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/home/runner/go/pkg/mod/github.com/urfave/cli/v2@v2.27.6/command.go:269\ngithub.com/urfave/cli/v2.(*App).RunContext\n\t/home/runner/go/pkg/mod/github.com/urfave/cli/v2@v2.27.6/app.go:333\ngithub.com/urfave/cli/v2.(*App).Run\n\t/home/runner/go/pkg/mod/github.com/urfave/cli/v2@v2.27.6/app.go307\nmain.main\n\t/home/runner/work/docker builds/docker builds/temporal/cmd/server/main.go55\nruntime.main\n\t/opt/hostedtoolcache/go/1.23.2/x64/src/runtime/proc.go:272"}
k
The knowledge sources do not contain enough information to fully diagnose this issue. However, looking at your logs, there are two distinct errors: Error 1: dial tcp 0.0.0.07233 connect: connection refused This is the same binding issue discussed earlier. The Temporal CLI is trying to connect to 
0.0.0.0:7233
instead of the pod's actual IP. As mentioned previously, the suggested fix from a known GitHub issue is: [Temporal Pod Issue]
Copy code
temporal:
  extraEnv:
    - name: BIND_ON_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
Error 2: unsupported OTEL exporter protocol: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf This is a separate error causing the Temporal server to fail to start. The Temporal server is rejecting the 
http/protobuf
value for 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
. This suggests somewhere in your configuration (likely via 
global.metrics.otel.*
or an 
extraEnv
) this variable is being set. You may want to either: ā€¢ Unset 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
entirely, or ā€¢ Override it on the temporal pod:
Copy code
temporal:
  extraEnv:
    - name: BIND_ON_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
      value: ""
    - name: DBNAME
      value: "temporal"
    - name: VISIBILITY_DBNAME
      value: "temporal_visibility"
    - name: SKIP_DB_CREATE
      value: "false"
However, I want to be transparent ā€” the knowledge sources do not explicitly confirm either of these fixes for Helm V2. I'd recommend checking the Airbyte GitHub issues and community Slack for more targeted guidance. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, I've tried to change the BIND_ON_IP with the pod's IP, but it is still failing. Additionally I have another airbyte installation on an EC2 with abctl where the BIND_ON_IP is 0.0.0.0 and it is working fine
k
The knowledge sources do not contain enough information to fully diagnose why 
BIND_ON_IP
is not resolving your issue, or why 
0.0.0.0
works fine in your 
abctl
EC2 installation but not in your Helm V2 Kubernetes deployment. What the knowledge sources do suggest is that the root cause in Kubernetes deployments is typically a mismatch between the address Temporal binds to and the address other pods try to connect to. [Temporal Pod Issue] However, based on your logs, the more likely culprit preventing Temporal from starting is actually Error 2 from my previous response:
Copy code
unsupported OTEL exporter protocol: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
This error causes the Temporal server process to exit before it even starts listening on any address ā€” which would explain why 
BIND_ON_IP
changes have no effect. The 
0.0.0.0:7233 connection refused
is likely a symptom of Temporal never starting, not the root cause. I'd recommend focusing on the OTEL error first: 1. Check if 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
is being set somewhere in your Helm values (e.g., under 
global.metrics
or any 
extraEnv
). 2. Try explicitly unsetting it on the temporal pod as suggested previously. Beyond that, the knowledge sources do not contain enough detail to guide you further. I'd strongly recommend opening a GitHub issue at airbytehq/airbyte with your full Helm values and logs. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, in config map airbyte-airbyte-env I have the following OTEL vars: OTEL_COLLECTOR_ENDPOINT: "" OTEL_EXPORTER_OTLP_ENDPOINT: "" OTEL_EXPORTER_OTLP_PROTOCOL: grpc OTEL_EXPORTER_OTLP_TIMEOUT: "30000" OTEL_METRIC_EXPORT_INTERVAL: "10000" OTEL_METRICS_EXPORTER: otlp OTEL_RESOURCE_ATTRIBUTES: service.name=templates,deployment.environment=%!s(<nil>),service.version=2.0.1
k
The knowledge sources do not contain enough information to definitively confirm this, but based on your ConfigMap and the error in your logs, here is what stands out: Your ConfigMap does not contain 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
, but the Temporal error explicitly references:
Copy code
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
This means this variable is being set somewhere else ā€” likely injected automatically by the Helm chart or inherited from another source. A few things to investigate: 1. Check if the Helm chart is auto-injecting it ā€” run:
Copy code
kubectl get pod <temporal-pod-name> -o yaml | grep -i otel
This will show all env vars actually present in the pod, revealing where 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
is coming from. 2. Also note this in your ConfigMap:
Copy code
OTEL_RESOURCE_ATTRIBUTES: service.name=templates,deployment.environment=%!s(<nil>),service.version=2.0.1
The 
%!s(<nil>)
suggests a template rendering issue in your Helm values where a variable is not being set correctly (likely 
global.deploymentEnv
or similar). 3. Try explicitly overriding the problematic variable on the temporal pod:
Copy code
temporal:
  extraEnv:
    - name: OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
      value: ""
I'd recommend starting with step 1 to identify the source before applying any fix. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, I've tried overriding it, but it seems it is not picking it up.
k
The knowledge sources do not contain enough information to help you further with this specific OTEL/Temporal issue in Helm V2. Given that: 1. 
BIND_ON_IP
changes are not taking effect 2. 
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
override via 
extraEnv
is not being picked up This suggests the environment variables may be getting overridden by the Helm chart's generated ConfigMap or another source with higher precedence. I'd recommend the following next steps outside of what I can confirm from the knowledge sources: 1. Verify what's actually in the pod at runtime:
Copy code
kubectl exec -n airbyte <temporal-pod-name> -- env | grep -i otel
2. Check all ConfigMaps being mounted into the temporal pod:
Copy code
kubectl get pod <temporal-pod-name> -o yaml | grep -i configmap
3. Open a GitHub issue at airbytehq/airbyte with your full Helm values (redacted) and pod logs ā€” this appears to be a Helm V2-specific bug that the Airbyte maintainers would need to address directly. 4. Ask in the Airbyte community Slack at airbytehq.slack.com ā€” this type of deployment-specific issue is likely to get faster and more targeted help there. I apologize that I cannot be more helpful here ā€” this goes beyond what the available knowledge sources cover. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, should the auth config like global.instanceAdmin .emailSecretKey and global.instanceAdmin.passwordSecretKey be in airbyte-config-secrets or in airbyte-auth-secrets ?
k
Based on the knowledge sources, there is some confusion around this ā€” and it has been a known bug in earlier Helm chart versions. What the Documentation Says The official documentation states that the password should be stored in 
airbyte-auth-secrets
: [Authentication Docs]
Copy code
apiVersion: v1
kind: Secret
metadata:
  name: airbyte-auth-secrets
type: Opaque
stringData:
  instance-admin-password: # password
What the Helm Values Say The 
values.yaml
file references 
airbyte-config-secrets
 as the secret name, with keys like 
instance-admin-email
and `instance-admin-password`: [Enterprise Implementation Guide]
Copy code
global:
  auth:
    instanceAdmin:
      secretName: "airbyte-config-secrets"
      emailSecretKey: "instance-admin-email"
      passwordSecretKey: "instance-admin-password"
The Known Bug There is a known bug where 
global.auth.instanceAdmin.secretName
is ignored by the bootloader, which hardcodes the secret name to 
airbyte-auth-secrets
regardless of what you set. [GitHub Issue #65154] [GitHub Issue #54685] Practical Recommendation Given the bug, the safest approach is to put your credentials in 
airbyte-auth-secrets
 as the documentation states, since that is what the bootloader actually reads from regardless of your 
values.yaml
configuration. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, is this correct auth block: auth: enabled: true secretName: airbyte-auth-secrets instanceAdmin: firstName: "ss" lastName: "aa" emailSecretKey: "instance-admin-email" passwordSecretKey: "instance-admin-password"
k
Based on the knowledge sources, your auth block looks mostly correct, but there are a few things to note: What Looks Correct ā€¢ 
enabled: true
āœ… ā€¢ 
emailSecretKey: "instance-admin-email"
āœ… ā€¢ 
passwordSecretKey: "instance-admin-password"
āœ… These key names match what the documentation shows inside 
airbyte-auth-secrets
. [Authentication Docs] Potential Issue The 
secretName: airbyte-auth-secrets
at the 
auth
level (not 
instanceAdmin
level) is not clearly documented in the knowledge sources. Based on the known bug where 
instanceAdmin.secretName
is ignored and the bootloader always hardcodes 
airbyte-auth-secrets
, having it at the 
auth
level may not have any effect either. [GitHub Issue #65154] What the Knowledge Sources Confirm Works The pattern confirmed to work in practice is:
Copy code
global:
  auth:
    enabled: true
    instanceAdmin:
      firstName: "ss"
      lastName: "aa"
      emailSecretKey: "instance-admin-email"
      passwordSecretKey: "instance-admin-password"
With your credentials stored directly in the 
airbyte-auth-secrets
Kubernetes secret:
Copy code
apiVersion: v1
kind: Secret
metadata:
  name: airbyte-auth-secrets
type: Opaque
stringData:
  instance-admin-email: # your email
  instance-admin-password: # your password
I cannot fully confirm whether 
secretName
at the 
auth
level is a valid V2 key, as the knowledge sources do not explicitly document it. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, can I used API GATEWAY instead of ingress ?
k
The knowledge sources briefly mention API Gateway as an option. The enterprise implementation guide states: > "You may configure ingress using a load balancer or an API Gateway." [Enterprise Implementation Guide] So yes, API Gateway is supported as an alternative to a standard Kubernetes ingress. However, the knowledge sources do not provide: ā€¢ Any specific configuration examples for API Gateway ā€¢ Which API Gateway providers are supported (e.g., AWS API Gateway, Kong, etc.) ā€¢ Any known limitations or caveats The only other thing the knowledge sources confirm is that service meshes like Istio are explicitly not supported: > "We do not currently support most service meshes (such as Istio)." [Enterprise Implementation Guide] And regardless of what you use for ingress/gateway, you must ensure 
global.airbyteUrl
matches the URL your gateway exposes:
Copy code
global:
  airbyteUrl: https://airbyte.example.com
For specific API Gateway configuration guidance, I'd recommend checking the Airbyte community Slack or opening a GitHub discussion. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, from which secret the bootload pod is reading the instanceAdmin params?
k
Based on the knowledge sources, the bootloader always reads from 
airbyte-auth-secrets
, regardless of what 
secretName
you set in your 
values.yaml
. This is the known bug documented in GitHub ā€” the bootloader hardcodes the secret name to `airbyte-auth-secrets`: [GitHub Issue #65154]
Copy code
- name: AB_INSTANCE_ADMIN_PASSWORD
  valueFrom:
    secretKeyRef:
      name: "airbyte-auth-secrets"  # āŒ Always hardcoded, ignores values.yaml
      key: "instance-admin-password"
This is also confirmed by the bootloader logs which show it explicitly initializing and updating `airbyte-auth-secrets`: [GitHub Issue #75614]
Copy code
INFO  Initializing auth secret in Kubernetes...
INFO  Using existing value for secret key instance-admin-password
INFO  Secret with name airbyte-auth-secrets already exists. Updating it...
INFO  Successfully updated secret airbyte-auth-secrets
Practical Takeaway Make sure your 
instance-admin-email
and 
instance-admin-password
are stored in 
airbyte-auth-secrets
:
Copy code
apiVersion: v1
kind: Secret
metadata:
  name: airbyte-auth-secrets
type: Opaque
stringData:
  instance-admin-email: # your email
  instance-admin-password: # your password
The 
secretName
field in your 
values.yaml
is effectively ignored by the bootloader. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, they are stored in that secret, but the bootloader is looking in secret airbyte-airbyte-secrets instead
k
The knowledge sources do not contain enough information to confirm why the bootloader is reading from 
airbyte-airbyte-secrets
instead of 
airbyte-auth-secrets
in Helm V2. What the knowledge sources do confirm is that in Helm V1 the bootloader hardcodes 
airbyte-auth-secrets
. [GitHub Issue #65154] It is possible that in Helm V2 the hardcoded secret name has changed from 
airbyte-auth-secrets
to 
airbyte-airbyte-secrets
, but I cannot confirm this from the knowledge sources. What I'd Suggest 1. Verify what secret the bootloader pod is actually referencing at runtime:
Copy code
kubectl get pod <bootloader-pod-name> -n airbyte -o yaml | grep -i secret
2. If it is indeed reading from 
airbyte-airbyte-secrets
, try adding your credentials to that secret instead:
Copy code
kubectl patch secret airbyte-airbyte-secrets -n airbyte \
  --type merge \
  -p '{"stringData": {
    "instance-admin-email": "your@email.com",
    "instance-admin-password": "yourpassword"
  }}'
3. Alternatively, use the 
extraEnv
workaround on the bootloader to explicitly point to your secret: [GitHub Issue #65154]
Copy code
airbyteBootloader:
  extraEnv:
    - name: AB_INSTANCE_ADMIN_EMAIL
      valueFrom:
        secretKeyRef:
          name: "airbyte-auth-secrets"
          key: "instance-admin-email"
    - name: AB_INSTANCE_ADMIN_PASSWORD
      valueFrom:
        secretKeyRef:
          name: "airbyte-auth-secrets"
          key: "instance-admin-password"
I'd strongly recommend opening a GitHub issue or asking in the Airbyte community Slack to get a definitive answer on the correct secret name for Helm V2. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, I've already tried with extraEnv approach, but the logs shows: rror: failed pre-install: warning: Hook pre-install airbyte/templates/airbyte-bootloader/pod.yaml failed: server-side apply failed for object airbyte/airbyte-bootloader /v1, Kind=Pod: failed to create typed patch object (airbyte/airbyte-bootloader; /v1, Kind=Pod): .spec.containers[name="airbyte-bootloader-container"].env: duplicate entries for key [name="AB_INSTANCE_ADMIN_PASSWORD"]
k
This is exactly the same class of bug documented in the knowledge sources ā€” the Helm chart is already injecting 
AB_INSTANCE_ADMIN_PASSWORD
into the bootloader pod, and your 
extraEnv
is creating a duplicate entry. [GitHub Issue #65154] [GitHub Issue #58591] This means the bootloader already has 
AB_INSTANCE_ADMIN_PASSWORD
injected by the chart ā€” it is just pointing to the wrong secret (
airbyte-airbyte-secrets
). What You Can Do Since you cannot override via 
extraEnv
due to the duplicate key error, your options are: 1. Create/patch the 
airbyte-airbyte-secrets
secret with your credentials, since that is what the chart is actually reading from:
Copy code
kubectl create secret generic airbyte-airbyte-secrets \
  -n airbyte \
  --from-literal=instance-admin-email=your@email.com \
  --from-literal=instance-admin-password=yourpassword \
  --dry-run=client -o yaml | kubectl apply -f -
2. Check the exact key names the bootloader expects in that secret:
Copy code
kubectl get pod <bootloader-pod-name> -n airbyte -o yaml | grep -A5 "AB_INSTANCE_ADMIN"
This will show you the exact 
secretKeyRef.key
values being used. The knowledge sources do not contain enough information to confirm the exact key names used in 
airbyte-airbyte-secrets
for Helm V2. I'd recommend checking the Airbyte community Slack or opening a GitHub issue for a definitive answer. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, how to configure in values.yaml an ingress with type alb? I have: ingress: enabled: true className: "alb" annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/listen-ports: '{"HTTP": 80}]' alb.ingress.kubernetes.io/ssl-redirect: 'false' but when I deploy airbyte via helm no ingress is being created, what I'm missing ?
k
Based on the knowledge sources, your 
ingress
block is missing the required 
hosts
configuration. Without a 
hosts
entry, the ingress resource will not be created. [Helm Chart Ingress] Here is the corrected configuration:
Copy code
ingress:
  enabled: true
  className: "alb"
  annotations:
    kubernetes.io/ingress.class: "alb"
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/ssl-redirect: "false"
  hosts:
    - host: airbyte.example.com  # replace with your domain
      paths:
        - path: /
          pathType: Prefix
          backend: server  # routes to airbyte-server
        - path: /connector-builder
          pathType: Prefix
          backend: connector-builder-server  # required for connector builder
  tls: []
Also ensure 
global.airbyteUrl
matches your ingress host: [Ingress URL Match]
Copy code
global:
  airbyteUrl: http://airbyte.example.com
Key Things to Check 1. 
hosts
block is required ā€” this was missing from your config and is why no ingress was being created. 2. ALB controller must be installed in your cluster before the ingress resource can be provisioned. [Ingress Prerequisites] 3. Fix the 
listen-ports
annotation ā€” your original had a mismatched bracket 
'{"HTTP": 80}]'
, it should be 
'[{"HTTP": 80}]'
. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
9 Views
Open in Slack
PreviousNext
Powered by