Unexpected required setting: backups.objectStorage.config.secret
Summary
When disabling minio from chart, and even if I set a global.appConfig.backups
bucket (cf. Configuration used
below) I must set a backups.objectStorage.config.secret
.
Steps to reproduce
Try to deploy using the specfic keys in configuration below.
Configuration used
global:
minio:
enabled: false
appConfig:
lfs:
bucket: mygitlab-gitlab-git-lfs
connection:
secret: gitlab-bucket-sa
key: connection
artifacts:
bucket: mygitlab-gitlab-artifacts
connection:
secret: gitlab-bucket-sa
key: connection
uploads:
bucket: mygitlab-gitlab-uploads
connection:
secret: gitlab-bucket-sa
key: connection
packages:
bucket: mygitlab-gitlab-packages
connection:
secret: gitlab-bucket-sa
key: connection
backups:
bucket: mygitlab-gitlab-backups
tmpBucket: mygitlab-gitlab-backups-temp
connection:
secret: gitlab-bucket-sa
key: connection
# ???
gitlab:
task-runner:
backups:
objectStorage:
config:
secret: "backup-secret"
Current behavior
While the deploying works if I put those settings, the task-runners
are not started because the backup-secret
does not exist.
While checking the Charts Repo, I found this which make me think that this is related to AWS S3 in some kind of way. Since I'm using GKE and GCS buckets and that backups bucket have already been defined, why should I reset it again in another way ? Am I missing anything ?
Expected behavior
Not having to populate vars about backups bucket twice, and using already defined credentials/secrets information.
Versions
- Chart: master
- Platform:
- Cloud: GKE
- Kubernetes:
- Client: v1.11.3
- Server: v1.11.2-gke.18
- Helm:
- Client: v2.11.0
- Server: v2.11.0
Edited by Dogo Good Enough