Go: berglas pkg/auto imports must panic on failure

[ahmetb]

I'm doing

import _ "github.com/GoogleCloudPlatform/berglas/pkg/auto"

in my Go app and it starts/boots just fine (on Kubernetes, or on Cloud Run), only later I find out it actually printed some log lines with errors about secrets initialization.

As a user I expect app to crash ASAP as there's no point of moving the app forward if a requirement cannot be initialized. It's certain that app will crash, and crashing early is a very conventional readiness/health check (recognized by runtimes like Kubernetes or Cloud Run).

[ahmetb]

What's actually bad in my case is that it leaves ENV_VAR=berglas://foo/bar and this causes the string to be actually used, and therefore weird errors like "could not be connected to the database, wrong password" which could make users think "uh oh, did my password just change".

[sethvargo]

Hey @ahmetb

This was an early design decision, the primary goal being portability between runtimes (e.g. the same code should work on GCP, locally, and on another cloud).

Adding such behavior greatly impedes the local development process, especially since Go doesn't have a good way to conditionally include imports across environments.

It's worth noting that berglas exec doesn't have this challenge, as it's expected to exit when a ref fails.

Curious your thoughts?

[ahmetb]

If I have an env var set to berglas:// it means I want it to be replaced for that, I can’t think of a scenario where silently failing is desired behavior. I can think of all the scenarios where failing ASAP makes a lot of sense.

[ahmetb]

Thanks for fixing this!