[usage] Configure DB credentials and connect

[easyCZ]

Description

Configures usage component to receive DB connection details and attempts to establish a connection to ensure it works.

Related Issue(s)

• Depends on [usage] Establish database connection #10218

How to test

usage component starts in Preview Env k8s

Release Notes

NONE

Documentation

NONE

[easyCZ]

/werft run

👍 started the job as gitpod-build-mp-db-conn-config.3
(with .werft/ from main)

[geropl]

The component is up and running.

But I noticed that it's the only component with container restarts, and it seems because the DB was not up, yet:

[error] failed to initialize database, got error dial tcp 10.43.21.69:3306: connect: connection refused
{"@type":"type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent","error":"dial tcp 10.43.21.69:3306: connect: connection refused","level":"fatal","message":"Failed to establish database connection.","serviceContext":{"service":"usage","version":"commit-744d6665468d952b21d0cc17fbf036b32df09039"},"severity":"CRITICAL","time":"2022-05-30T08:32:39Z"}

Other DB dependent pods use the service-waiter component, e.g. here.

One could argue that "failing fast" is Kubernetes best practice, and that's true to some degree. But experience showed that it's very valuable to be able to quickly tell if "everything is fine", and that's not possible when there's too much noise. service-waiter effectively adds a delay of 30s, which is a nice compromise between "fail quick enough" and "keep good signal to noise ratio".

[easyCZ]

@geropl Yep aware. Wanted to see if this becomes a problem or not. I can add the waiter in a follow-up PR. As it stands, it's only really a problem in preview after a fresh deploy.

And absolutely agree, in an ideal world this is already self-healing in k8s envs.