Default Config of Helm Chart should result in a working instance of OpenBao

[voigt]

Describe the bug

Installing the OpenBao helm chart with default config results in a malfunctioning setup. The OpenBao instance starts in an uninitialized and sealed state. This is why the readiness probe (bao status) fails, and ultimately no traffic is directed to via the service.

To Reproduce

$ helm install openbao \
  --namespace openbao \
  --create-namespace \
  --debug \
  charts/openbao

Check openbao pods, openbao-0 will never become ready.

Expected behavior

I understand that it is hard to provide a production ready config for the openbao helm chart (is it?). But I think the next best would be at least a working setup, so a user can tinker with openbao on Kubernetes.

Environment

• Kubernetes version: all
• openbao-helm version: main

Additional context

I've been working on adding smoke test installations of the helm chart for various k8s distributions (#53). With the way openbao-helm currently installs openbao, the tests would be insufficient/meaningless.
My current idea is to exec into the pod and initialize/unseal the instance. But I feel like this shouldn't be part of the test.

[cipherboy]

Hey @voigt Yes, I agree -- this would be good to have ideally. I drafted openbao/openbao#1341 to discuss a potential approach to solving this.

Happy to take input and thoughts on it, though do note it is a very rough sketch at the moment!

[eyenx]

Hi @voigt, I really like the idea. From my POV, there is a BUT, though.

Making it so easy to spin up might lead to productive environments being set up without considering storage and proper configuration, which makes me a little unsure if we should fully go for a working instance of OpenBao with self-initialization included.

We discussed this on the train with @pree and @Nerkho, and we were more thinking about having self-initialization or even the server -dev command as an opt-in feature. This would make it easy to quickly deploy an instance for users to tinker with before making some thoughtful decisions on how to proceed with proper configuration.

[eyenx]

Now that self-init is a thing, do we want to achieve this? Probably by setting a value which is "false" by default and has a disclaimer?