https://linen.dev logo
Join Slack
Powered by
I'm at 1.7.2 version in Linus can I run abctl inst...
# replication-ask-ai
r
I'm at 1.7.2 version in Linus can I run abctl install to upgrade to airbyte last version?
k
Yes, you can upgrade from Airbyte 1.7.2 to the latest version on Linux using 
abctl
, but you must upgrade 
abctl
first before upgrading the Airbyte instance [Upgrading Airbyte deployed with abctl; abctl 0.30.2 required]. Upgrading to newer versions (such as Airbyte 2.0+) requires 
abctl
version 0.30.2 or later (which uses Helm Chart V2 by default) [Upgrade to Helm chart V2 (Core); abctl 0.30.2 required]. Upgrade Steps on Linux 1. Upgrade the abctl tool Run the installation script to update 
abctl
to the latest version [Upgrading Airbyte deployed with abctl]:
Copy code
curl -LsfS https://get.airbyte.com | bash -
Verify the tool was upgraded:
Copy code
abctl version
2. Upgrade the Airbyte Instance Once 
abctl
is up to date, run:
Copy code
abctl local install
(If you are using custom configuration values, include your flags, e.g., 
abctl local install --values values.yaml
) [Install and manage local Airbyte instances]. 3. Verify the Deployment Check that the deployment has upgraded successfully [Install and manage local Airbyte instances]:
Copy code
abctl local status
Important Notes â€ĸ Custom Values Compatibility: Because Airbyte 1.7+ and 2.x transition to Helm Chart V2, if you use a custom 
values.yaml
file, you may need to update its syntax to match V2 chart standards [Upgrade to Helm chart V2 (Core)]. â€ĸ Breaking Changes: When jumping across major releases, review the release notes for any breaking configuration changes [Multiple issues with 2.0.0 chart]. 👍 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
r
@kapa.ai I have 0.30.4 abctl, do I need to intall helm chart even running abctl local instal?
k
No, you do not need to install the Helm chart manually. 
abctl
automatically creates the local cluster (using 
kind
) and handles the installation of the Airbyte and NGINX Ingress Helm charts for you under the hood [abctl]. To upgrade or install your instance, simply run [Install and manage local Airbyte instances]:
Copy code
abctl local install
If you have custom settings, you can pass a values file directly to 
abctl
using the 
--values
flag without needing to run any 
helm
commands [Install and manage local Airbyte instances]:
Copy code
abctl local install --values values.yaml
👍 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
r
@kapa.ai that is my config, do I need upgrade helm chart?
Copy code
INFO    Using Kubernetes provider:
            Provider: kind
            Kubeconfig: /home/glpd/.airbyte/abctl/abctl.kubeconfig
            Context: kind-airbyte-abctl
 SUCCESS  Found Docker installation: version 28.3.3
 SUCCESS  Existing cluster 'airbyte-abctl' found
  INFO    Found helm chart 'airbyte-abctl'
            Status: deployed
            Chart Version: 1.7.2
            App Version: 1.7.2
  INFO    Found helm chart 'ingress-nginx'
            Status: deployed
            Chart Version: 4.13.0
            App Version: 1.13.0
  INFO    Airbyte should be accessible via <http://localhost:8000>
k
No, you do not need to manually upgrade the Helm chart using 
helm
commands [abctl]. Since you are managing your local deployment with 
abctl
(version 0.30.4), 
abctl
manages the Helm charts automatically [abctl]. Starting with version 0.30.0, 
abctl
already uses Helm Chart V2 by default [Upgrade to Helm chart V2 (Core)]. To upgrade your Airbyte instance and its underlying Helm chart to the latest version, simply run [Install and manage local Airbyte instances]:
Copy code
abctl local install
After the command finishes, verify the new version with [Install and manage local Airbyte instances]:
Copy code
abctl local status
👍 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
r
@kapa.ai got a error:
Copy code
ERROR   Failed to install airbyte/airbyte Helm Chart
  ERROR   Unable to install Airbyte locally
  ERROR   unable to install airbyte chart: unable to install helm: cannot patch "airbyte-abctl-cron" with kind Deployment: Deployment.apps "airbyte-abctl-cron" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"airbyte":"cron", "<http://app.kubernetes.io/instance|app.kubernetes.io/instance>":"airbyte-abctl", "<http://app.kubernetes.io/name|app.kubernetes.io/name>":"cron"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "airbyte-abctl-server" with kind Deployment: Deployment.apps "airbyte-abctl-server" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"airbyte":"server", "<http://app.kubernetes.io/instance|app.kubernetes.io/instance>":"airbyte-abctl", "<http://app.kubernetes.io/name|app.kubernetes.io/name>":"server"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "airbyte-abctl-temporal" with kind Deployment: Deployment.apps "airbyte-abctl-temporal" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"airbyte":"temporal", "<http://app.kubernetes.io/instance|app.kubernetes.io/instance>":"airbyte-abctl", "<http://app.kubernetes.io/name|app.kubernetes.io/name>":"temporal"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "airbyte-abctl-worker" with kind Deployment: Deployment.apps "airbyte-abctl-worker" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"airbyte":"worker", "<http://app.kubernetes.io/instance|app.kubernetes.io/instance>":"airbyte-abctl", "<http://app.kubernetes.io/name|app.kubernetes.io/name>":"worker"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && cannot patch "airbyte-abctl-workload-api-server" with kind Deployment: Deployment.apps "airbyte-abctl-workload-api-server" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"airbyte":"workload-api-server", "<http://app.kubernetes.io/instance|app.kubernetes.io/instance>":"airbyte-abctl", "<http://app.kubernetes.io/name|app.kubernetes.io/name>":"workload-api-server"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable && failed to create patch: The order in patch list:
k
This error occurs because newer versions of the Helm chart changed the deployment label selectors (
spec.selector
), and Kubernetes deployment selectors are immutable once created [Helm chart broken with abctl 0.30.1]. As a result, Helm cannot patch the existing deployments in place. To resolve this when upgrading with 
abctl
, you need to perform an uninstall and reinstall cycle. Running 
abctl local uninstall
removes the Kubernetes resources while preserving your persistent data [Uninstall Airbyte; Full abctl reference]. Solution 1. *Uninstall the current deployment (preserves data):*abctl local uninstall_(Do not include the 
--persisted
flag, as that would delete your data [Uninstall Airbyte; Full abctl reference].)_ 2. *Reinstall with the latest version:*abctl local install_(Include any custom flags/values you previously used, such as 
--values ./values.yaml
or 
--insecure-cookies
[Github Issue (closed): [abctl] Unending "DEBUG helm: Deployment is not ready..."; Could not deploy latest (v1.6.0) airbyte community with abctl...])._ 3. *Verify the status:*abctl local status If you still hit an error If you are passing a custom 
values.yaml
file, make sure the keys conform to the Helm chart V2 syntax (e.g., camelCase like 
workloadLauncher
instead of 
workload-launcher
), as outdated V1 values syntax can also cause patch and migration failures [Upgrade to Helm chart V2 (Core)]. 👍 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
r
@kapa.ai i've uninstall and did abctl local install --low-resource-mode and got the error:
Copy code
ERROR   Cluster 'airbyte-abctl' could not be created
  ERROR   unable to create kind cluster: command "docker run --name airbyte-abctl-control-plane --hostname airbyte-abctl-control-plane --label io.x-k8s.kind.role=control-plane --privileged --security-opt seccomp=unconfined --security-opt apparmor=unconfined --tmpfs /tmp --tmpfs /run --volume /var --volume /lib/modules:/lib/modules:ro -e KIND_EXPERIMENTAL_CONTAINERD_SNAPSHOTTER --detach --tty --label io.x-k8s.kind.cluster=airbyte-abctl --net kind --restart=on-failure:1 --init=false --cgroupns=private --volume /dev/mapper:/dev/mapper --volume=/home/glpd/.airbyte/abctl/data:/var/local-path-provisioner --publish=0.0.0.0:8000:80/TCP --publish=127.0.0.1:36049:6443/TCP -e KUBECONFIG=/etc/kubernetes/admin.conf kindest/node:v1.32.2@sha256:f226345927d7e348497136874b6d207e0b32cc52154ad8323129352923a3142f" failed with error: exit status 125: 8c0614d0e20ed167b30d7f5510e3234ba925f553ea04d8b89d744e6e69ba849f
          docker: Error response from daemon: failed to create task for container: failed to create shim task: failed to create OCI runtime console socket: mkdir /tmp/pty3975576641: no space left on device: unknown

          Run 'docker run --help' for more information
k
This error occurs directly at the Docker and host system level:
Copy code
docker: Error response from daemon: failed to create task for container: failed to create shim task: failed to create OCI runtime console socket: mkdir /tmp/...: no space left on device
Docker cannot create the control-plane container for the local Kubernetes cluster (
kind
) because your host machine's 
/tmp
directory or Docker storage volume has run out of disk space or available inodes [Failing to install Helm chart locally; Cluster 'airbyte-abctl' could not be created]. How to Resolve 1. Check disk space and inodes on your Linux host Run these commands to see which filesystem is full:
Copy code
df -h /tmp
df -i /tmp
â€ĸ If 
df -h
shows 100% (or near 100%) capacity, free up disk space on that partition. â€ĸ If 
df -i
shows 100% inode usage (
%iused
), you have too many small/temporary files and need to delete unused files. 2. Clean up unused Docker resources Old containers, unused images, and build caches often consume the available disk space:
Copy code
docker system prune -a --volumes
(Note: This removes unused Docker images, stopped containers, and dangling volumes). 3. Clear temporary files if /tmp is mounted separately If 
/tmp
is on a small 
tmpfs
or dedicated partition, check and remove old temporary files:
Copy code
sudo rm -rf /tmp/pty*
4. Retry the installation Once space is freed up, run the installation command again:
Copy code
abctl local install --low-resource-mode
👍 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
r
@kapa.ai it wordked, I've upgraded to 2.2 version, but I cannot see the log of the job is stuck running: No logs found for this job.
k
When upgrading across versions to Airbyte 2.x, seeing jobs stuck running with "No logs found for this job" typically happens for one of the following reasons based on known issues: 1. Dataplane Group Mismatch (Most Common after 1.7.x → 2.x upgrades) When upgrading from 1.7.x to 2.x, the bootloader sometimes registers the 
workload-launcher
under a new dataplane group UUID while workloads continue to be routed to the old group [Dataplane Group Mismatch After Upgrade]. As a result, the workload launcher never claims the job, the pod is never created, and no logs are produced [Dataplane Group Mismatch After Upgrade]. How to verify and fix: 1. Check the 
workload-launcher
pod logs. If it is not claiming workloads and only running pod sweeper cycles (missing 
ApiQueuePoller
lines), you are likely hitting this issue [Dataplane Group Mismatch After Upgrade]:kubectl logs -n airbyte-abctl deployment/airbyte-abctl-workload-launcher 2. Connect to the Airbyte database container:kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U docker -d airbyte 3. Check the dataplane group IDs:SELECT id, status, dataplane_group FROM workload WHERE status = 'pending'; SELECT d.id, d.dataplane_group_id, dg.name FROM dataplane d JOIN dataplane_group dg ON dg.id = d.dataplane_group_id WHERE d.tombstone = false; 4. If there is a mismatch between the group IDs, update all dataplanes to match the group where workloads are being sent [Dataplane Group Mismatch After Upgrade]:UPDATE dataplane SET dataplane_group_id = 'target-dataplane-group-id'; 5. Restart the workload launcher deployment [Dataplane Group Mismatch After Upgrade]:kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl 2. MinIO / Log Storage Disk is Full Airbyte stores sync and attempt logs in MinIO by default. If the MinIO persistent storage reaches capacity (default PVC size can fill quickly), the platform fails to write logs and jobs hang indefinitely [All sync jobs hanging indefinitely; S3 Minio Storage Full]. How to check and fix: 1. Exec into the MinIO container and delete old logs to free up space [All sync jobs hanging indefinitely; How to clean up airbyte-minio]:kubectl exec -it -n airbyte-abctl airbyte-minio-0 -- sh 2. Inside the container, remove the old job logs [All sync jobs hanging indefinitely]:rm -rf /storage/airbyte-storage/job-logging/workspace/* rm -rf /storage/airbyte-storage/workload/output/* 3. Check Workload and Connector Pods Directly If the pod is failing or stuck before reporting logs back to the UI, you can inspect the Kubernetes pods directly to find container-level logs [Collect Logs from a Flex Data Plane]:
Copy code
# Check if any job pods were launched
kubectl get pods -n airbyte-abctl -l airbyte=job-pod

# View the orchestrator / sync container logs directly
kubectl logs -n airbyte-abctl <pod-name> -c orchestrator
👍 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
r
@kapa.ai STG? [glpd@duschdvs-glmis-tac41 ~]$ kubectl logs -n airbyte-abctl deployment/airbyte-abctl-workload-launcher -bash: kubectl: command not found STG? [glpd@duschdvs-glmis-tac41 ~]$ kubectl get pods -n airbyte-abctl -l airbyte=job-pod -bash: kubectl: command not found
k
kubectl
is a standard Kubernetes command-line tool, but it is not installed automatically by 
abctl
[Troubleshooting abctl]. To use 
kubectl
with an instance managed by 
abctl
, you need to: 1. Install 
kubectl
 on your Linux machine (e.g., via your Linux package manager or by downloading the official binary). 2. Point 
kubectl
to the 
abctl
kubeconfig file located at 
~/.airbyte/abctl/abctl.kubeconfig
[Troubleshooting abctl]. Option 1: Use kubectl by specifying the kubeconfig Once 
kubectl
is installed on your host, include the 
--kubeconfig
flag in your commands [Troubleshooting abctl]:
Copy code
# View pods in the cluster
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods

# View workload-launcher logs
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl logs deployment/airbyte-abctl-workload-launcher
You can also set the 
KUBECONFIG
environment variable in your session so you don't have to pass the flag every time [error 502 - Error on airbyte-abctl-worker]:
Copy code
export KUBECONFIG=~/.airbyte/abctl/abctl.kubeconfig
kubectl get pods -n airbyte-abctl
Option 2: Inspect built-in abctl deployments directly Without installing 
kubectl
, you can view deployment status or restart deployments using built-in 
abctl
commands [Install and manage local Airbyte instances]:
Copy code
# View deployment information
abctl local deployments

# Restart Kubernetes deployments
abctl local deployments --restart
👍 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
r
@kapa.ai
Copy code
root@airbyte-abctl-control-plane:/# kubectl get pods -n airbyte-abctl -l airbyte=job-pod
No resources found in airbyte-abctl namespace.
k
Because 
kubectl get pods -n airbyte-abctl -l airbyte=job-pod
returns "No resources found", no job or replication pods are being created by the system [Github Issue (closed): workload-launcher false positive liveness probes under lost storage connection; Dataplane Group Mismatch After Upgrade]. This explains why the UI is stuck and displays "No logs found for this job" [Dataplane Group Mismatch After Upgrade]. This is a known issue after upgrading from Airbyte 1.7.x to 2.x caused by a dataplane group ID mismatch [Dataplane Group Mismatch After Upgrade]. Root Cause During the upgrade/reinstall, the bootloader registers the 
workload-launcher
under a new dataplane group UUID, but jobs/workloads continue to be routed to the existing 
AUTO
dataplane group [Dataplane Group Mismatch After Upgrade]. Because the workload-launcher only polls its own registered group, it never claims the jobs, no pods are launched, and jobs remain pending indefinitely [Dataplane Group Mismatch After Upgrade]. How to Fix From inside your control-plane container (or from your host if configured), run the following steps: 1. Check the Workload Launcher Logs Verify if the launcher is only running pod sweeper cycles without polling the queue [Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl logs -n airbyte-abctl deployment/airbyte-abctl-workload-launcher
2. Fix the Dataplane Group in the Database Connect to the PostgreSQL database pod and align the dataplanes to the 
AUTO
group [Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U docker -d airbyte
Inside the PostgreSQL shell (
psql
), run the following SQL update [Dataplane Group Mismatch After Upgrade]:
Copy code
UPDATE dataplane
SET dataplane_group_id = (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
)
WHERE dataplane_group_id != (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
);
\q
3. Restart the Workload Launcher Restart the launcher deployment so it reinitializes its queue poller with the updated group [Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl
4. Verify Check the logs again to confirm polling has resumed [Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl logs -n airbyte-abctl deployment/airbyte-abctl-workload-launcher | grep ApiQueuePoller
You should see log messages indicating 
Resuming ApiQueuePoller with <group-id>
[Dataplane Group Mismatch After Upgrade]. Once active, triggering a sync will spin up the job pods and display logs normally [Workload launching architecture]. 👍 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
r
@kapa.ai step 2: psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: role "docker" does not exist
k
This error occurs because the PostgreSQL user role is set to 
postgres
(or 
airbyte
) rather than 
docker
in your database container [Forum Post: Airbyte kubernetes/helm deployment unable to configure external postgres; Github Issue (closed): [abctl] failure to connect to airbyte-db postgresql]. Try connecting using the 
postgres
user instead [Step 2: Configure your PostgreSQL database]:
Copy code
kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U postgres -d airbyte
(If 
postgres
also fails, try with 
-U airbyte
[Forum Post: Source connection throws unrelated error]). Once you are inside the 
psql
prompt, run the SQL update to fix the dataplane group mismatch [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
UPDATE dataplane
SET dataplane_group_id = (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
)
WHERE dataplane_group_id != (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
);
Exit `psql`:
Copy code
\q
Then proceed to restart the workload launcher [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl
👍 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
r
@kapa.ai root@airbyte-abctl-control-plane:/# kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U airbyte -d airbyte psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: database "airbyte" does not exist command terminated with exit code 2 root@airbyte-abctl-control-plane:/# kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U postgres -d airbyte psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: role "postgres" does not exist command terminated with exit code 2
k
The error messages indicate that: 1. The user 
airbyte
exists, but the database named 
airbyte
does not. 2. The user 
postgres
does not exist. You can connect to PostgreSQL using the existing 
airbyte
user and target the default 
postgres
database (or connect without specifying 
-d
to inspect the available databases) [Forum Post: Error while cloning Airbyte repository]. Step 1: List the Databases Connect with user 
airbyte
to the 
postgres
default database and list all databases:
Copy code
kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U airbyte -d postgres -c "\l"
Step 2: Connect to the Correct Database and Apply the Fix In the output list from the command above, identify the database used by Airbyte (it may be named 
postgres
, 
defaultdb
, or another name). Connect to that database (replace 
<database_name>
with the name found):
Copy code
kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U airbyte -d <database_name>
Once inside the 
psql
shell, execute the update query to resolve the dataplane mismatch [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
UPDATE dataplane
SET dataplane_group_id = (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
)
WHERE dataplane_group_id != (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
);
\q
Step 3: Restart the Workload Launcher After updating the database, restart the workload launcher [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl
👍 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
r
@kapa.ai Name | Owner | Encoding | Locale Provider | Collate | Ctype | Locale | ICU Rules | Access privileges ---------------------+---------+----------+-----------------+------------+------------+--------+-----------+--------------------- db-airbyte | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | postgres | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | template0 | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/airbyte + | | | | | | | | airbyte=CTc/airbyte template1 | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | =c/airbyte + | | | | | | | | airbyte=CTc/airbyte temporal | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | | temporal_visibility | airbyte | UTF8 | libc | en_US.utf8 | en_US.utf8 | | |
k
The target database is 
db-airbyte
. Step 1: Run the Dataplane Update Query Connect to 
db-airbyte
with the 
airbyte
user and apply the update query [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl exec -it -n airbyte-abctl airbyte-db-0 -- psql -U airbyte -d db-airbyte -c "
UPDATE dataplane
SET dataplane_group_id = (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
)
WHERE dataplane_group_id != (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
);
"
Step 2: Restart the Workload Launcher Restart the workload-launcher deployment so it begins polling the updated dataplane group [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl
Step 3: Verify the Fix Check the workload-launcher logs to confirm the queue poller is active [Github Issue (open): Dataplane Group Mismatch After Upgrade]:
Copy code
kubectl logs -n airbyte-abctl deployment/airbyte-abctl-workload-launcher | grep ApiQueuePoller
You should see lines indicating:
Copy code
INFO  Resuming ApiQueuePoller with <AUTO-group-id> and high
INFO  Resuming ApiQueuePoller with <AUTO-group-id> and default
Once confirmed, retry your sync job; it should launch pods and display logs normally [Github Issue (open): Dataplane Group Mismatch After Upgrade]. 👍 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
3 Views
Open in Slack
PreviousNext
Powered by