https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> --values not working with abtcl air...
# replication-ask-ai
i
@kapa.ai --values not working with abtcl airbyte version 2
k
abctl
supports a 
--values
flag, but it does not let you pick an arbitrary Airbyte app version directly. Instead: - 
abctl local install
always installs/upgrades to the latest Airbyte version; there is no flag to choose a specific version. [[Support QA](#)] - You can pass a Helm values file for configuration with:
Copy code
bash   abctl local install --values ./values.yaml
This is the documented way to customize the installation (resources, host, secrets, etc.). [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] If 
--values
“is not working” for you, the common documented error is:
Copy code
text unable to merge values with values file './values.yaml': unable to read values from yaml file './values.yaml': failed to read file ./values.yaml: open ./values.yaml: no such file or directory
In that case, you must ensure: 1. You are running 
abctl
from the directory where 
values.yaml
actually exists, or 2. You pass the correct path, e.g. 
--values /full/path/to/values.yaml
. [[Troubleshoot deploy](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#unable-to-read-values-from-yaml-file)] So: - You can use 
--values
to customize the deployment. - You cannot use 
abctl
to lock to a specific Airbyte version; it always targets the latest, and the values file only controls configuration, not the version itself. [[Support QA](#)]
A message from kapa.ai
For 
abctl
, 
--values
is only for passing a Helm values file, not for selecting an Airbyte version. From the docs: - 
abctl local install
always installs/upgrades to the latest Airbyte Helm chart/app version; there is no flag in 
abctl
to pin a specific version. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] - To customize the installation, you pass your config file with:
Copy code
bash   abctl local install --values ./values.yaml
The values file controls settings (host, resources, etc.), not the Airbyte version itself. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference); Support QA] If 
--values
appears “not working”, the only documented error is when the file cannot be read:
Copy code
text unable to merge values with values file './values.yaml': unable to read values from yaml file './values.yaml': failed to read file ./values.yaml: open ./values.yaml:  no such file or directory
In that case, ensure: - You are in the directory that actually contains 
values.yaml
, or - You point to the correct path, e.g. 
--values /path/to/values.yaml
. [[Unable to read values](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#unable-to-read-values-from-yaml-file)] There is no documented way in 
abctl
to install “Airbyte version 2.x” specifically; for strict version pinning you must use Helm directly instead of 
abctl
(Helm commands and version selection are shown in the install/upgrade docs). [[Installing Airbyte](https://docs.airbyte.com/platform/deploying-airbyte#5-installing-airbyte); [Upgrading Airbyte](https://docs.airbyte.com/platform/operator-guides/upgrading-airbyte)]
i
@kapa.ai when including --values i get failed. when not includes that everything is ok
k
A message from kapa.ai
When 
abctl local install
works without 
--values
but fails with it, the most common documented cause is that 
abctl
cannot read the file you passed. The error looks like:
Copy code
text unable to merge values with values file './values.yaml': unable to read values from yaml file './values.yaml': failed to read file ./values.yaml: open ./values.yaml: no such file or directory
In that case, the docs say to verify: 1. You are in the correct directory (where 
values.yaml
is located), or 2. You are passing the correct path to the file, e.g.:
Copy code
bash abctl local install --values /full/path/to/values.yaml
[[Unable to read values](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#unable-to-read-values-from-yaml-file)] Also, the 
--values
flag is only for configuration overrides; it does not control the Airbyte version, and 
abctl
is designed to install/upgrade to the latest version. [[Support QA](#); [abctl local install](https://docs.airbyte.com/platform/deploying-airbyte/abctl#install-and-manage-local-airbyte-instances)] If you can share the exact error message you see when using 
--values
, I can help pinpoint whether it’s this “cannot read file” case or something else that isn’t covered in the docs.
i
@kapa.ai i get this readOnly: false - mountPath: /lib/modules name: lib-modules readOnly: true hostNetwork: true nodeSelector: kubernetes.io/os: linux serviceAccountName: kindnet tolerations: - operator: Exists volumes: - hostPath: path: /etc/cni/net.d name: cni-cfg - hostPath: path: /run/xtables.lock type: FileOrCreate name: xtables-lock - hostPath: path: /lib/modules name: lib-modules DEBUG kind - INFO: ✓ Installing CNI 🔌 DEBUG kind - INFO: • Installing StorageClass 💾 ... DEBUG kind - INFO: ✓ Installing StorageClass 💾 DEBUG kind - INFO: • Waiting ≤ 5m0s for control-plane = Ready ⏳ ... DEBUG kind - INFO: ✓ Waiting ≤ 5m0s for control-plane = Ready ⏳ DEBUG kind - INFO: • Ready after 16s 💚 SUCCESS Cluster 'airbyte-abctl' created INFO Patching image airbyte/db:1.7.0-17 DEBUG helm: release installed successfully: airbyte-2-1765881263/airbyte-2.0.19 INFO Pulling image airbyte/async-profiler:2.0.1 INFO Pulling image airbyte/bootloader:2.0.1 INFO Pulling image airbyte/connector-builder-server:2.0.1 INFO Pulling image airbyte/connector-sidecar:2.0.1 INFO Pulling image airbyte/container-orchestrator:2.0.1 INFO Pulling image airbyte/cron:2.0.1 INFO Pulling image airbyte/db:1.7.0-17 INFO Pulling image airbyte/server:2.0.1 INFO Pulling image airbyte/utils:2.0.1 INFO Pulling image airbyte/worker:2.0.1 INFO Pulling image airbyte/workload-api-server:2.0.1 INFO Pulling image airbyte/workload-init-container:2.0.1 INFO Pulling image airbyte/workload-launcher:2.0.1 INFO Pulling image temporalio/auto-setup:1.27.2 DEBUG error pulling image Error response from daemon: manifest for airbyte/async-profiler:2.0.1 not found: manifest unknown: manifest unknown DEBUG error pulling image Error response from daemon: manifest for airbyte/utils:2.0.1 not found: manifest unknown: manifest unknown DEBUG found existing image with ref docker.io/kindest/kindnetd:v20250214-acbabc1a DEBUG found existing image with ref docker.io/kindest/local-path-helper:v20241212-8ac705d0 DEBUG found existing image with ref docker.io/kindest/local-path-provisioner:v20250214-acbabc1a DEBUG found existing image with ref registry.k8s.io/coredns/coredns:v1.11.3 DEBUG found existing image with ref registry.k8s.io/etcd:3.5.16-0 DEBUG found existing image with ref registry.k8s.io/kube-apiserver-amd64:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-apiserver:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-controller-manager-amd64:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-controller-manager:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-proxy-amd64:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-proxy:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-scheduler-amd64:v1.32.2 DEBUG found existing image with ref registry.k8s.io/kube-scheduler:v1.32.2 DEBUG found existing image with ref registry.k8s.io/pause:3.10 DEBUG found existing image with ref sha256:85b7a174738baecbc53029b7913cd430a2060e0cbdb5f56c7957d32ff7f241ef DEBUG found existing image with ref sha256:873ed75102791e5b0b8a7fcd41606c92fcec98d56d05ead4ac5131650004c136 DEBUG found existing image with ref sha256:a9e7e6b294baf1695fccb862d956c5d3ad8510e1e4ca1535f35dc09f247abbfc DEBUG found existing image with ref sha256:b6a454c5a800d201daacead6ff195ec6049fe6dc086621b0670bca912efaf389 DEBUG found existing image with ref sha256:baa0d31514ee559c8962d6469a23315bcc8342cbbc1eccc49fa803dcd9653cb7 DEBUG found existing image with ref sha256:bbb6209cc873b9b4095bd014b4687512eea2bd7b246f9ec06f4f6f0be14d9fb6 DEBUG found existing image with ref sha256:c69fa2e9cbf5f42dc48af631e956d3f95724c13f91596bc567591790e5e36db6 DEBUG found existing image with ref sha256:d8e673e7c9983f1f53569a9d2ba786c8abb42e3f744f77dc97a595f3caf9435d DEBUG found existing image with ref sha256:df3849d954c98a7162c7bee7313ece357606e313d98ebd68b7aac5e961b1156f DEBUG found existing image with ref sha256:f1332858868e1c6a905123b21e2e322ab45a5b99a3532e68ff49a87c2266ebc5 DEBUG image does not exist: sha256:61d35bb52ea60d69f9370f423d607b570fed20762c3c48aba104ad4a40bce91f [airbyte/connector-builder-server:2.0.1] DEBUG image does not exist: sha256:de3becfb2fe4b9dacf8f451ba92951572991fac5cbaab9279dbee75276cd336b [airbyte/cron:2.0.1] DEBUG image does not exist: sha256:d8377bdf08f8e0aa5d20daa1fae54f83746f6eefca1cffe49afaf7cc285557ac [airbyte/server:2.0.1] DEBUG image does not exist: sha256:e2a0d56fd627022185cd897093c58d0f330543c803c362560205d558a7619080 [airbyte/bootloader:2.0.1] DEBUG image does not exist: sha256:865ba61eca5338aaad309a6dad027f142f7dc9c9e4e6b0fde21956c4c061d036 [airbyte/worker:2.0.1] DEBUG image does not exist: sha256:56d2130c988ad5dda23c64402f21662545a120c0e6a29ea976a21e5313b6de2a [airbyte/connector-sidecar:2.0.1] DEBUG image does not exist: sha256:3fa68f1b19158e1b8ba6425967d0a99b528f9a0b2d3717bdad64d85c473c5eb7 [airbyte/workload-api-server:2.0.1] DEBUG image does not exist: sha256:80598943cff75ec039972e968319de0406142fd14b03654ed62dfc93a6e6d97d [airbyte/workload-launcher:2.0.1] DEBUG image does not exist: sha256:1ed225f93e22b417137fd07bf430fc359c9569d4c0b248994ac24790a5ba183d [airbyte/container-orchestrator:2.0.1] DEBUG image does not exist: sha256:5df13b07113879aab9ec97e02d8dda972df52b3938d885e1d19b30d310dcf6cb [airbyte/workload-init-container:2.0.1] DEBUG image does not exist: sha256:3e7f68452b6a385f22351573d764fb11fff378352912a0c0eebb5ced9710ce61 [airbyte/db:1.7.0-17] DEBUG image does not exist: sha256:6697cac6ce122978874e3c18368ac1a8b2ad8efb47dfa4d10b2a8523ce636586 [temporalio/auto-setup:1.27.2] DEBUG saving image archive to /tmp/images-tar-4284378034/images.tar DEBUG loading image archive into kind node airbyte-abctl-control-plane DEBUG Event watcher started. INFO Namespace 'airbyte-abctl' created DEBUG Creating directory '/root/.airbyte/abctl/data/airbyte-local-pv' DEBUG Updating permissions for '/root/.airbyte/abctl/data/airbyte-local-pv' INFO Persistent volume 'airbyte-local-pv' created INFO Persistent volume claim 'airbyte-storage-pvc' created DEBUG Creating directory '/root/.airbyte/abctl/data/airbyte-volume-db' DEBUG Updating permissions for '/root/.airbyte/abctl/data/airbyte-volume-db' INFO Persistent volume 'airbyte-volume-db' created INFO Persistent volume claim 'airbyte-volume-db-airbyte-db-0' created DEBUG helm: WARNING: repository name "airbyte" already exists INFO Starting Helm Chart installation of 'airbyte/airbyte' (version: 2.0.19) DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-admin" ServiceAccount DEBUG helm: Ignoring delete failure for "airbyte-admin" /v1, Kind=ServiceAccount: serviceaccounts "airbyte-admin" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-admin-role" Role DEBUG helm: Ignoring delete failure for "airbyte-admin-role" rbac.authorization.k8s.io/v1, Kind=Role: roles.rbac.authorization.k8s.io "airbyte-admin-role" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-admin-binding" RoleBinding DEBUG helm: Ignoring delete failure for "airbyte-admin-binding" rbac.authorization.k8s.io/v1, Kind=RoleBinding: rolebindings.rbac.authorization.k8s.io "airbyte-admin-binding" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-abctl-airbyte-env" ConfigMap DEBUG helm: Ignoring delete failure for "airbyte-abctl-airbyte-env" /v1, Kind=ConfigMap: configmaps "airbyte-abctl-airbyte-env" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-abctl-airbyte-secrets" Secret DEBUG helm: Ignoring delete failure for "airbyte-abctl-airbyte-secrets" /v1, Kind=Secret: secrets "airbyte-abctl-airbyte-secrets" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Starting delete for "airbyte-abctl-bootloader" Pod DEBUG helm: Ignoring delete failure for "airbyte-abctl-bootloader" /v1, Kind=Pod: pods "airbyte-abctl-bootloader" not found DEBUG helm: beginning wait for 1 resources to be deleted with timeout of 1h0m0s DEBUG helm: creating 1 resource(s) DEBUG helm: Watching for changes to Pod airbyte-abctl-bootloader with timeout of 1h0m0s DEBUG Successfully assigned airbyte-abctl/airbyte-abctl-bootloader to airbyte-abctl-control-plane DEBUG helm: Add/Modify event for airbyte-abctl-bootloader: ADDED DEBUG helm: Pod airbyte-abctl-bootloader pending DEBUG helm: Add/Modify event for airbyte-abctl-bootloader: MODIFIED DEBUG helm: Pod airbyte-abctl-bootloader pending DEBUG Container image "airbyte/bootloader:2.0.1" already present on machine DEBUG Created container: airbyte-bootloader-container DEBUG Started container airbyte-bootloader-container DEBUG helm: Add/Modify event for airbyte-abctl-bootloader: MODIFIED DEBUG helm: Pod airbyte-abctl-bootloader running DEBUG helm: Add/Modify event for airbyte-abctl-bootloader: MODIFIED DEBUG helm: Pod airbyte-abctl-bootloader running DEBUG helm: Add/Modify event for airbyte-abctl-bootloader: MODIFIED ERROR Failed to install airbyte/airbyte Helm Chart DEBUG looking at airbyte-abctl-bootloader Failed() DEBUG found logs: Unsetting empty environment variable 'AB_INSTANCE_ ERROR Unable to install Airbyte locally DEBUG Received unexpected event: *v1.Status DEBUG Event watcher completed. ERROR unable to install airbyte chart: unable to install helm: failed pre-install: 1 error occurred: * pod airbyte-abctl-bootloader failed
k
A message from kapa.ai
The logs show two distinct issues: 1. Missing Docker images for Airbyte 2.0.1 
abctl
is trying to pull: - 
airbyte/async-profiler:2.0.1
- 
airbyte/utils:2.0.1
and Docker reports:
Copy code
text    manifest for airbyte/async-profiler:2.0.1 not found: manifest unknown    manifest for airbyte/utils:2.0.1 not found: manifest unknown
This matches known, open reports where 
abctl local install
(and Helm charts ≥ 1.6.0) reference 
airbyte/async-profiler
tags that do not exist on Docker Hub. [[Issue 61339](https://github.com/airbytehq/airbyte/issues/61339); [Issue 63742](https://github.com/airbytehq/airbyte/issues/63742)] In those issues, users confirm: - Pulling 
airbyte/async-profiler:<version>
fails because the tag is not published. - The problem is specific to certain chart/abctl versions; some people work around it by using different chart versions or options (e.g. 
--low-resource-mode
with a newer platform), but there is no documented, reliable fix via 
abctl
itself yet. [[Issue 61339](https://github.com/airbytehq/airbyte/issues/61339); [Issue 63742](https://github.com/airbytehq/airbyte/issues/63742)] The docs do not currently document a configuration flag in 
values.yaml
to disable 
async-profiler
or 
utils
, nor a supported way in 
abctl
to pin a different, working version of the platform. The internal Support QA also states that 
abctl
always targets the latest version and you cannot directly select another app version; 
--values
is only for configuration overrides. > “The 
abctl
tool currently does not provide a direct way to install a specific version of Airbyte. It is designed to install or upgrade to the latest version of Airbyte.” [[Support QA](#)] Because of this, I cannot point you to a documented 
values.yaml
change that will make 
abctl
stop pulling these missing images. 2. Helm bootloader pod failing After image handling, Helm fails on the bootloader hook:
Copy code
text    ERROR   Failed to install airbyte/airbyte Helm Chart    ...    * pod airbyte-abctl-bootloader failed
There is an open issue with the same symptom on local 
abctl
installs (
pod airbyte-abctl-bootloader failed
), but the shared thread does not include a confirmed, documented resolution from the Airbyte side yet. [[Issue 50429](https://github.com/airbytehq/airbyte/issues/50429)] --- ### What is documented / what you can do Given the current documentation and issues: - The failure is consistent with known missing images and a failing bootloader hook in local 
abctl
installs of recent versions. [[Issue 61339](https://github.com/airbytehq/airbyte/issues/61339); [Issue 63742](https://github.com/airbytehq/airbyte/issues/63742); [Issue 50429](https://github.com/airbytehq/airbyte/issues/50429)] - There is no documented, supported way to: - Use 
--values
to change the platform version that 
abctl
installs, or - Configure 
abctl
to avoid pulling 
airbyte/async-profiler
/ 
airbyte/utils
for version 2.0.1. The only fully documented way to pin a working version today is to bypass 
abctl
and use Helm directly, where you can choose chart and app versions, and optionally a custom image registry: - Install with Helm chart v2 (example for 2.0.x):
Copy code
bash   helm install airbyte airbyte-v2/airbyte \     --namespace airbyte-v2 \     --values ./values.yaml \     --version 2.0.18      # chart version
[[Installing Airbyte](https://docs.airbyte.com/platform/deploying-airbyte#5-installing-airbyte)] - Customize your deployment and (optionally) set a custom registry in `values.yaml`:
Copy code
yaml   global:     image:       registry: <http://ghcr.io/NAMESPACE|ghcr.io/NAMESPACE>
and, if needed, 
imagePullSecrets
for private registries. [[Custom image registry (Enterprise)](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#configure-a-custom-image-registry); [Same (Next)](https://docs.airbyte.com/platform/next/enterprise-setup/implementation-guide#configure-a-custom-image-registry)] Using Helm directly also lets you set 
global.image.tag
when applicable for 1.8-style deployments. [[Customizing 1.8](https://docs.airbyte.com/platform/1.8/enterprise-setup/implementation-guide#customizing-your-deployment)] --- ### Summary - Your failure with 
--values
is not about the file itself; the logs show 
abctl
successfully reading it and then failing because it pulls images (
async-profiler:2.0.1
, 
utils:2.0.1
) that do not exist, plus a bootloader hook failure. - These image/tag problems and 
abctl
local failures are known and currently tracked in GitHub issues; there is no documented 
values.yaml
-based fix. - For now, the documented, controllable path to a stable version is using Helm directly (not 
abctl
) and pinning a known-good chart/app version, optionally combined with a custom registry if your environment requires it.
i
but if i omit the --values it works correctly.
@kapa.ai but if i omit the --values it works correctly. so do i have a problem with external database?
k
A message from kapa.ai
It’s unlikely that this specific failure is caused by the external database itself; it’s more about how 
abctl
behaves when you add 
--values
. From what you shared: - With 
--values
, `abctl`: - Creates the kind cluster successfully. - Starts pulling Airbyte images (2.0.1). - Then the bootloader pod fails: 
unable to install airbyte chart: ... * pod airbyte-abctl-bootloader failed
Bootloader failures are a known, general class of issues with 
abctl
and are usually due to the bootloader not being able to reach the Airbyte database (the in-cluster 
airbyte-db
service).[[Troubleshooting abctl](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#airbyte-bootloader-failed-to-start)] However, the docs do not document a specific case where simply adding 
--values
(for an external DB or otherwise) causes a bootloader failure in v2. What is documented: - For `abctl`: - 
--values
is only a Helm values override; it does not change how versions are picked. [[abctl reference](https://docs.airbyte.com/platform/deploying-airbyte/abctl#reference)] - Bootloader failures show up as the exact error you see, and the official guidance is to inspect the bootloader logs (which 
abctl
already prints) and note that causes are “generally related” to DB connectivity. [[Troubleshooting abctl](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#airbyte-bootloader-failed-to-start)] - For external databases with Helm: - There is a pattern of issues where misconfigured external DB values can make the bootloader hang or fail, but the specific example in the forum was resolved by upgrading the chart, not by changing DB settings. [[Helm external DB post](https://discuss.airbyte.io/t/3787)] Because your install succeeds without 
--values
 but fails with it, the failure is almost certainly related to something in that values file (for example, external DB configuration), not an 
abctl
bug that is completely independent of values. But: - The knowledge sources you provided do not contain: - A 2.0.x example of external DB configuration for 
abctl
. - A confirmed bug that “external DB via 
--values
breaks 
abctl
while default DB works” for v2. So, based only on the docs: 1. The symptom (
pod airbyte-abctl-bootloader failed
) is consistent with a DB connectivity/config issue. [[Troubleshooting abctl](https://docs.airbyte.com/platform/deploying-airbyte/troubleshoot-deploy#airbyte-bootloader-failed-to-start)] 2. The fact that “no 
--values
works” means the default embedded DB path works. 3. I cannot definitively say from the docs whether your external DB config is wrong, only that: - When you enable it (via 
--values
), the bootloader fails. - That pattern matches the “bootloader cannot connect to DB” class of problems. To move forward, you’d need to: - Compare your 
values.yaml
against a known-good external DB example (for Helm v2) and confirm host, port, database name, user, password/secret references, and SSL settings. - Or temporarily remove just the external DB section from 
values.yaml
and see if the install then works with `--values`; if it does, that isolates the issue to the DB configuration. The current knowledge sources don’t show the exact 
values.yaml
you’re using, so I can’t validate it directly or point to a specific misconfiguration line.
2 Views
Open in Slack
PreviousNext
Powered by