-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Existing secret config.env doens't work #2328
Comments
@D1StrX this may be resolved in 6.0.4 based on another user report - @harshavardhana @pjuarezd we need to cut that release fully |
@ravindk89 Updated to v6.0.4. Another issue arise: configuration:
name: <secret>
configSecret:
existingSecret: true and tried configuration:
name: <secret>
configSecret:
name: <secret>
existingSecret: true and tried configSecret:
name: <secret>
existingSecret: true |
Apparently configuration:
name: <secret>
configSecret:
name: <secret>
accessKey:
secretKey:
existingSecret: true Makes sense with the default |
Another issue arise:
|
Can you provide your full values.yaml with PII redacted? |
Here we go: # Root key for MinIO Tenant Chart
tenant:
name: example
image:
repository: quay.io/minio/minio
tag: RELEASE.2024-10-02T17-50-41Z
pullPolicy: IfNotPresent
imagePullSecret: {}
scheduler: {}
configuration:
name: minio-example-env-configuration
configSecret:
accessKey:
secretKey:
name: minio-example-env-configuration
existingSecret: true
pools:
- servers: 4
name: pool-0
volumesPerServer: 2
size: 15Gi
storageClassName: standard
storageAnnotations: {}
annotations: {}
labels: {}
tolerations: []
nodeSelector: []
affinity: {}
resources: {}
securityContext:
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
fsGroupChangePolicy: "OnRootMismatch"
runAsNonRoot: true
containerSecurityContext:
runAsUser: 1000
runAsGroup: 1000
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
seccompProfile:
type: RuntimeDefault
topologySpreadConstraints: []
mountPath: /export
subPath: /data
metrics:
enabled: false
port: 9000
protocol: http
certificate:
externalCaCertSecret: []
externalCertSecret:
- name: external-minio-certificate
type: kubernetes.io/tls
requestAutoCert: false
certConfig: {}
features:
bucketDNS: false
domains: {}
enableSFTP: false
buckets:
- name: example-bucket
users:
- name: example-user
podManagementPolicy: Parallel
liveness: {}
readiness: {}
startup: {}
lifecycle: {}
exposeServices: {}
serviceAccountName: ""
prometheusOperator: false
logging: {}
serviceMetadata: {}
env:
- name: MINIO_STORAGE_CLASS_STANDARD
value: EC:2
- name: MINIO_SITE_REGION
value: <region>
priorityClassName: ""
additionalVolumes: []
additionalVolumeMounts: []
# Set the keys to conform to the Ingress controller and configuration of your choice.
ingress:
api:
enabled: false
console:
enabled: true
ingressClassName: "controller"
labels:
service: minio-console
annotations:
cert-manager.io/cluster-issuer: <issuer>
nginx.org/ssl-services: "example-console"
nginx.org/websocket-services: "example-console"
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/proxy-body-size: "5t"
nginx.org/client-max-body-size: "0"
nginx.ingress.kubernetes.io/configuration-snippet: |
chunked_transfer_encoding off;
tls:
- hosts:
- console.domain.tld
secretName: minio-console-tls-secret
host: console.domain.tld
path: /
pathType: Prefix |
Possibly, I will defer to engineering on this cc/ @jiuker in case this rings a bell |
If you can reproduce it locally, please write a detail steps.Like what command, what script |
It seems the error solved itself... unfortunately not able to pin-point what exactly could've caused it. Feeling says this was network related, not the application. |
That's correct but when we're using this chart as a dependency (as a subchart), we cannot override these values since an empty string or null would be replaced by the chart's defaults. The current only way to fix this is to remove the default values from the chart which shouldn't be an issue since these keys need to be customized. @ravindk89 should I create another issue or is it clear enough? |
IMHO the documentation could be improved in the |
https://github.com/minio/operator/blob/master/helm/tenant/values.yaml#L54-L57 I actually wonder what is the value of having @pjuarezd @jiuker what do y'all think? Do we really benefit from keeping |
Expected Behavior
Only the existing secret should exist when
tenant.configSecret.existingSecret:
true
.Current Behavior
When
tenant.configSecret.existingSecret:
true
andtenant.configuration.name:
<secret name>
, there shouldn't be a secret created by MinIO. Yet in ArgoCD I can see that configSecret creates the default secret, despiteexistingSecret = true
. The other secret is deployed by a SealedSecret, which should be the only one existing.Possible Solution
Helm values should probably be looked after. Not sure where the problem lies.
Steps to Reproduce (for bugs)
Create a tenant with this config specifically, deployed by ArgoCD:
The existing secret is for example deployed with SealedSecrets.
Then you can clearly see 2 secrets are created. One by MinIO, one by SealedSecrets.
Context
Locks you out of your MinIO instance and Bucket creation fails with error
buckets creation failed: The Access Key Id you provided does not exist in our records.
Regression
Yes, since 6.0.0 due to secret deprecation.
Your Environment
minio-operator
): 6.0.3The text was updated successfully, but these errors were encountered: