Issue with DATABASE_URL not persisting in configmap during Airbyte deployment on EKS using Helm chart

Slack Knowledge Base Q&A Platform Questions
, , , ,
1

Summary

The user is facing an issue where DATABASE_URL is not persisting in the configmap airbyte-airbyte-env during Airbyte deployment on EKS using Helm chart. The value gets deleted every time helm upgrade is run in the airbyte-bootloader pod.


Question

Hi everyone. I’m stumped on this one. I’m trying to deploy airbyte v0.60.0 on EKS using helm chart v0.83.0. The issue seems to be that DATABASE_URL is not in the configmap airbyte-airbyte-env, and I can’t seem to get DATABASE_URL to persist in a configmap. It always gets deleted every time I run helm upgrade, in the airbyte-bootloader pod. Anyone have pointers on this? The AI gave good info but said to bring it up with the slack community :smile:


This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want
to access the original thread.

Join the conversation on Slack

["database-url", "configmap", "airbyte", "eks", "helm-chart", "airbyte-bootloader"]
2

and if so, do they have the same bug?

3

No that is the old deprecated db config block, you should use global.database

4

https://butt.holdings

5

okay that probably is totally solved, amazing and thank you! Now the only mystery to solve is why the helm install isn’t setting up the ingresses

6

it def was working yesterday, but it stopped suddenly…

7

We don’t have the ingress configuration as part of the Chart. There might be one that is baked into one of the subcharts, but its deprecated. We intend to add a top-level ingress config block for setting that up in the future. Right now you need to configure your ingress out of band

8

for both airbyte and the airbyte-api, yea?

9

btw, we’re upgrading from a 2 year old version of airbyte, new one looks super slick

10

> for both airbyte and the airbyte-api, yea?
Just the one that covers all the “public” endpoints

11

The big game changer in the new one in my opinion is google drive -> aws data lake

12

that’s unbelievably powerful

13

alright this is the issue I’m facing now (if you don’t mind continuing to assist me):

java.lang.RuntimeException: Cannot end publishing: Cannot publish to S3: The request signature we calculated does not match the signature you provided. Check your key and signing method. If you start to see this issue after you upgrade the SDK to 1.12.460 or later, it could be because the bucket provided contains '/'. See <https://github.com/aws/aws-sdk-java/discussions/2976> for more details (Service: Amazon S3; Status Code: 403; Error Code: SignatureDoesNotMatch; Request ID: 1EDCNN0JEFQV6TM9; S3 Extended Request ID: HiEgsgoYaeMzuXtaVkWQvN7v6ZvlorOEJSEy4Njc6OV9Dt5bMJShk2Qopk/WKQuh0cy+Y1sT5Ds=; Proxy: null)
I mean I get that it’s getting an access denied from aws. But I don’t understand why. As far as I can tell, I’ve set the helm chart with aws creds that I know are authorized to access all of our s3

14

and I also see AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set as env vars on the airbyte-server pod with the expected values

15

yea, because i was including the prefix

16

hey! here you go:

    type:
    secretName:
    hostSecretKey:
    portSecretKey:
    databaseSecretKey:
    userSecretKey:
    passwordSecretKey:
    urlSecretKey:```
17

Ok, I believe there is a bug with how host/port/database are handled from a secret. Please use the plaintext keys host, port and database

18

And remove their xxxSecretKey versions

19 
    type:
    secretName:
    host:
    port:
    database:
    userSecretKey:
    passwordSecretKey:```
20

I need to fill this section out as well as the externalDatabase section, right?