Closed tschlaepfer closed 2 weeks ago
Same for the openbao-standby
service; interestingly the openbao-internal
service does not suffer from this renaming remnant
I believe this was addressed by this PR in OpenBao: https://github.com/openbao/openbao/pull/416
But as mentioned there, we're hoping to land transactional storage before doing a v2.1.0 release. If that takes too long (as discussed on a prior meeting) and the maintainers get a bit more time, we'll think about doing a v2.0.1 in the interim.
Thanks!
Describe the bug When deploying OpenBao in an HA mode the ingress should point to the openbao-active service. Unfortunately, there is an issue with the selector for this service because it is looking for a pod with the label
openbao-active: "true"
, however, the active pod is labeled withvault-active: 'true'
. Hence, no endpoints can be found on the openbao-active service and the ingress is not working properly.The same issue applies to the openbao-standby service.
To Reproduce Steps to reproduce the behavior:
kubectl describe openbao-active service:
kubectl describe openbao-0
Expected behavior The label to indicate which pod is the active server in an HA setup of OpenBao as to correspond to the label set on the pod. So either update the OpenBao pod logic to set the active label to "openbao-active: true" or change the Helm chart to use the "vault-active" label.
Environment
Chart values: