Closed mhemken-vts closed 6 months ago
@bgroff can you take a look in this issue?
Update:
It looks like the airbyte-server suddenly has the variables AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
. No other component has these set. I have not added these variables in the configuration. Furthermore, I've edited the values.yaml to set those to empty strings. They are still set to the default admin/minio123.
Does that help narrow down the scope of this issue?
@mhemken-vts are you upgrading from a previous version? What steps you ran to get into the problem?
I recently upgraded from 0.50.50 to 0.64.151. The purpose of that upgrade was to be able to use IRSA to authenticate with AWS S3. Using minio for logs had been problematic. The upgrade and switch to S3 fixed it. Our users were finally able to see logs in the Airbyte UI (they were not available previously).
After that had been deployed to all environments, I moved on to doing the same thing with the database: replacing the db included in the helm chart with a stable one in RDS. The reason for this is that the helm chart uses helm-hooks to install the database. This means that the database's statefulset exists outside of the helm release's lifecycle. Maintenance was a pain.
The problem in this issue started after I configured the external database.
...continued
Points worth noting:
In a surprise move, it works now. To my knowledge, configuration didn't change. There was one colleague who repeatedly refreshed the helm release for an unrelated issue. That may have done it. Though, I don't understand why it was still broken when I did it.
Helm Chart Version
airbyte-0.64.151
What step the error happened?
Other
Relevant information
When I try to view the logs (Connection > Job History > > View Logs) I get the 500 error below. This configuration was working last week. I have deployed the helm chart on EKS and it is authenticating with the S3 bucket using IRSA. This configuration was tailing the logs correctly on Friday.
Relevant log output