OpenBao Helm installation is failing with error - "Unknown storage type postgresql"

[gsk1985]

Describe the bug OpenBao Helm installation is failing while running the server in Standalone mode with "postgresql" storage

To Reproduce Steps to reproduce the behavior:

1. Modify values.yaml -> “server.standalone.config” property with below value storage "postgresql" { connection_url = "postgres://pgadmin:q32OddAJNW6S1g45uItxWY6e7tC97B@100.101.242.175:5432/tca" table = "openbao_kv_store" ha_table = "openbao_ha_locks" upsert_function = "openbao_kv_put" skip_create_table = "true" }

2. Trigger Helm install

3. Below error is seen in openbao server log - Unknown storage type postgresql

Other useful info to include: openbao pod logs, kubectl describe statefulset openbao and kubectl get statefulset openbao -o yaml output

root@tca [ /home/admin ]# kubectl get pods -n openbao-vault
NAME                                      READY   STATUS             RESTARTS     AGE
openbao-0                                 0/1     CrashLoopBackOff   1 (4s ago)   10s
openbao-agent-injector-6dddcfdcbd-msxfq   0/1     Running            0            10s

root@tca [ /home/admin ]# kubectl logs openbao-0 -n openbao-vault
Unknown storage type postgresql
2024-10-16T15:24:13.811Z [WARN]  unknown or unsupported field disable_mlock found in configuration at /tmp/storageconfig.hcl:2:1
2024-10-16T15:24:13.811Z [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""

Expected behavior Openbao pods should be UP and running

Environment

• Kubernetes version: 1.27.x
  • Distribution or cloud vendor (OpenShift, EKS, GKE, AKS, etc.): standalone K8s cluster
  • Other configuration options or runtime services (istio, etc.):
• openbao-helm version: openbao-0.6.0

Helm chart info:

root@tca [ /home/admin ]# helm list -A | grep open
openbao     openbao-vault   1           2024-10-16 15:23:47.314176911 +0000 UTC deployed    openbao-0.6.0               v2.0.2   

Chart values:

  standalone:
    enabled: "-"

    # config is a raw string of default configuration when using a Stateful
    # deployment. Default is to use a PersistentVolumeClaim mounted at /openbao/data
    # and store data there. This is only used when using a Replica count of 1, and
    # using a stateful set. This should be HCL.

    # Note: Configuration files are stored in ConfigMaps so sensitive data
    # such as passwords should be either mounted through extraSecretEnvironmentVars
    # or through a Kube secret.  For more information see:
    # https://openbao.org/docs/platform/k8s/helm/run#protecting-sensitive-vault-configurations
    config: |
      ui = true

      listener "tcp" {
        tls_disable = 1
        address = "[::]:8200"
        cluster_address = "[::]:8201"
        # Enable unauthenticated metrics access (necessary for Prometheus Operator)
        #telemetry {
        #  unauthenticated_metrics_access = "true"
        #}
      }
      storage "postgresql" {
        connection_url = "postgres://pgadmin:q32OddAJNW6S1g45uItxWY6e7tC97B@100.101.242.175:5432/tca"
        table = "openbao_kv_store"
        ha_table = "openbao_ha_locks"
        upsert_function = "openbao_kv_put"
        skip_create_table = "true"
      }

      # Example configuration for using auto-unseal, using Google Cloud KMS. The
      # GKMS keys must already exist, and the cluster must have a service account
      # that is authorized to access GCP KMS.
      #seal "gcpckms" {
      #   project     = "openbao-helm-dev"
      #   region      = "global"
      #   key_ring    = "openbao-helm-unseal-kr"
      #   crypto_key  = "openbao-helm-unseal-key"
      #}

      # Example configuration for enabling Prometheus metrics in your config.
      #telemetry {
      #  prometheus_retention_time = "30s"
      #  disable_hostname = true
      #}
[](url)

Additional context Add any other context about the problem here.

[gsk1985]

looks like latest openbao-helm chart is still refering to openbao version v2.0.2 which doesn't support "PhysicalBackends" of type postgres.

Openbao main branch code has support for "PhysicalBackends" of type postgres , but there is no helm chart pointing to main branch.

[cipherboy]

@gsk1985 That is correct; we're working towards a 2.1.x release but it will still be a bit for it to come out.

[gsk1985]

@cipherboy Thanks for confirming. Could you please share tentative timelines for the 2.1.x release?