https://linen.dev logo
Join Slack
Powered by
:warning: :rotating_light: Deployment Configuratio...
# releases
u
⚠️ 🚨 Deployment Configuration Breaking Change Alert 🚨 ⚠️ The version 0.51.0 has a breaking change to Docker and Helm deployments. We’ve revamped how external logs are configured, making it much simpler. Be sure to watch out for upcoming migration documentation if you’re considering upgrading to this version. Remember to verify that your deployment uses the correct env variables. The team is working to update the migration docs to make simpler the transition. Stay tuned octavia thanks
c
Is this documentation now available? We are looking to upgrade our setup
❤️ 1
b
i'm also looking for migration documentation for v0.50.0 > 0.510 or later
r
@Marcos Marx (Airbyte) maybe this is the source of this issue? https://github.com/airbytehq/airbyte/issues/36401
would love pointers on this too
b
i had that same error on any bigquery destination 1.9.0 as well
from my quick digging it looks like (at least on a docker install), there is a permissions issue creating files in /tmp/workspace, because on v0.50.0 the container runs as id 0 and on later version it runs as id 1000.
a
@Carolina Buckler @Brad Clark there is documentation already for Helm deployments, there is a section called "Migrate from old chart to Airbyte v0.52.0 and latest chart version": https://docs.airbyte.com/deploying-airbyte/on-kubernetes-via-helm#migrate-from-old-chart-to-airbyte-v0520-and-latest-chart-version
thanku 1
b
ah, i'm not running it in kubernetes with helm right now, using the docker compose setup.
plus1 4
m
It looks can be related to some work to run containers without root anymore.
c
Getting 
RETRY_STATE_MAXIMUM_ATTEMPTS_REACHED
from testing the Destination connection with the new 
Enable Loading Data Incrementally to Final Tables
; Airbyte v0.51.0 and Snowflake 3.6.6
b
@[DEPRECATED] Marcos Marx my thought is that i could probably fix the volume file permissions then upgrade, and it might work.
c
Downgrading to 0.50.47, as suggested in the Github issue, worked
r
i imagine v0.50.54 might be the last version to work for everyone affected by this (but yeah i'm still on 0.50.47 too)
@Brad Clark if the approach happens to work for you, def share those steps! 🙏
plus1 3
@Marcos Marx (Airbyte) is there any way we can help with this issue? a bit of a selfish reason, but i'm going on paternity leave in ~2 weeks, and i'd love to upgrade to a more recent stable version (but i may not have enough time to test at this point)
👀 1
m
Hey Roberto I’m returning from vacation today. I’ll take a look and reutrn to you today
airbyte heart 1
r
love it, thanks so much Marcos! and hope you had a great vacay
a
@Brad Clark I am hitting this issue now too. Any luck with the permissions update?
@[DEPRECATED] Marcos Marx is there any documentation on how to address the permissions change when upgrading from v0.51.0 to v0.56.0 in a docker install?
🙏 3
r
has anyone found a fix?
a
Sadly I haven't and haven't been able to update because of it. @John (Airbyte) @[DEPRECATED] Marcos Marx @Chris Rose (Airbyte) (not sure if there is anyone else to tag), do you expect to give any guidance on how to work through the Docker breaking change?
m
Hello I’m getting in touch with the engineering team. Hope to get better docs and explanation next week.
🙏 3
a
Thank you so much!!! @[DEPRECATED] Marcos Marx
r
should we start looking into discarding our current environments and creating entirely new ones from scratch? 🥺
b
@Roberto Tolosa I hesitate to recommend it, but I was able to successfully upgrade to the newest version by stopping Airbyte and blowing away the 
airbyte_workspace
volume: 
docker volume rm airbyte_workspace
. I lost logs in the process, but each of my jobs picked up where they left off and appear to be working properly. The March 2024 release notes led me to this solution: https://docs.airbyte.com/release_notes/march_2024#platform-releases
r
niice, thanks for sharing and prob worth doing that! does losing the logs mean you still keep run history (but not the full logs)? or do you also lose run history? i'd prob be able to live with it
i might give this ownership change approach a shot first: https://chat.openai.com/share/92af948f-1a84-45d9-8b97-a7960ef59799 (it's ultimately just 
sudo chown -R 1000:1000 /path/to/mountpoint
)
b
Lost run history as well
Would rather have it than not, but not particularly bothered either - so long as the data syncs themselves are intact
➕ 1
Open in Slack
PreviousNext
Powered by