Issue 9: address failing tests in CI by fixing more references of vault to be openbao

[jessebot]

changes

• Fixes chart testing workflow failing due to old vault command? #9 by changing references the vault command to be bao, which certainly makes it fail a little better :)
• also changes references to the /vault/config dir to /openbao/config to match our current docker image
• changes directory that bats acceptance tests try to run helm commands to actual chart dir
• changes the bulk of the tests to use openbao vs vault in naming and mocking out stuff
• removes more references to licensing

Caveats

These acceptance tests can't be fully operational yet though, as we still need to have working openbao-k8s and openbao-csi-provider docker images.

[jessebot]

The current error we're getting in ci for this PR (this is after correcting vault to bao:

==> Logs of container openbao-zagktn68r5-server-test
------------------------------------------------------------------------------------------------------------------------
Checking for sealed info in 'bao status' output
Attempt 0...
Error checking seal status: Get "http://openbao-zagktn68r5.openbao-zagktn68r5.svc:8200/v1/sys/seal-status": dial tcp 10.96.239.182:8200: connect: connection refused

...<truncated for brevity>...

Attempt 9...
Error checking seal status: Get "http://openbao-zagktn68r5.openbao-zagktn68r5.svc:8200/v1/sys/seal-status": dial tcp 10.96.239.182:8200: connect: connection refused
timed out looking for sealed info in 'bao status' output

Also wanted to note that this job says it's still running, but it actually finished after about 5 minutes, because that's when the test times out: https://github.com/openbao/openbao-helm/actions/runs/9177571090/job/25235481635

update 1

a maintainer canceled the job :)

Update 2

this job will still complain until the openbao-k8s and openbao-csi-provider docker images are both available, so it's safe to wait on this PR for now.

Update 3

I need to do some more local testing on this, as now I'm not sure if it's failing because of openbao-k8s/openbao-csi-provider not being available as docker images or if it's failing because of the service name not being available?

Sleuthing... and looking at this failed job run:

 ==> Logs of container openbao-cvjh9yybky-0
------------------------------------------------------------------------------------------------------------------------
cp: cannot stat '/openbao/config/extraconfig-from-values.hcl': No such file or directory

Perhaps it's failing because it wanted to copy that file here:

Containers:
  vault:
    Container ID:  containerd://9872ca8838fb8970726286c64f431be7e2c6c1bd04788d62f3e02d052e82e961
    Image:         quay.io/openbao/openbao:2.0.0-alpha20240329
    Image ID:      quay.io/openbao/openbao@sha256:a015ae0adb1af5b45b33632e29879ff87063d0878e9359584a50b2706e500e9a
    Ports:         8200/TCP, 8201/TCP, 8202/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP
    Command:
      /bin/sh
      -ec
    Args:
      cp /openbao/config/extraconfig-from-values.hcl /tmp/storageconfig.hcl;
      [ -n "${HOST_IP}" ] && sed -Ei "s|HOST_IP|${HOST_IP?}|g" /tmp/storageconfig.hcl;
      [ -n "${POD_IP}" ] && sed -Ei "s|POD_IP|${POD_IP?}|g" /tmp/storageconfig.hcl;
      [ -n "${HOSTNAME}" ] && sed -Ei "s|HOSTNAME|${HOSTNAME?}|g" /tmp/storageconfig.hcl;
      [ -n "${API_ADDR}" ] && sed -Ei "s|API_ADDR|${API_ADDR?}|g" /tmp/storageconfig.hcl;
      [ -n "${TRANSIT_ADDR}" ] && sed -Ei "s|TRANSIT_ADDR|${TRANSIT_ADDR?}|g" /tmp/storageconfig.hcl;
      [ -n "${RAFT_ADDR}" ] && sed -Ei "s|RAFT_ADDR|${RAFT_ADDR?}|g" /tmp/storageconfig.hcl;
      /usr/local/bin/docker-entrypoint.sh bao server -config=/tmp/storageconfig.hcl 

which I think is declared here in the{{ template "vault.fullname" . }}-config ConfigMap:

openbao-helm/charts/openbao/templates/server-config-configmap.yaml

Lines 26 to 27 in b59b6e5

	extraconfig-from-values.hcl: |-
	{{ template "vault.config" . }}

why it's not available? I'm not sure. Need to sleuth further. I was able to locally do kubectl create ns openbao && ct install --namespace openbao --target-branch main and I got the following when checking the configmap with kubectl get cm openbao-6g0tg6wa8l-config -o yaml:

openbao-6g0tg6wa8l-config ConfigMap

apiVersion: v1
data:
  extraconfig-from-values.hcl: |2-

    disable_mlock = true
    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 "file" {
      path = "/vault/data
    }

    # 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     = "vault-helm-dev
    #   region      = "global
    #   key_ring    = "vault-helm-unseal-kr
    #   crypto_key  = "vault-helm-unseal-key
    #}

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

That |2- is kinda weird, but it doesn't seem like that's what broke it. sleuthing more...

[jessebot]

This should be good to go now, but as I said previously, we still need to move forward the other docker images before we can finish testing all angles of this helm chart for default functionality.