Skip to content
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

Provisioning job failing due to sleep timeout not being sufficient enough for minio cluster to be operational upon "mc admin service restart" command in provisioning job #30597

Closed
choudham opened this issue Nov 22, 2024 · 4 comments
Assignees
Labels
minio solved stale 15 days without activity tech-issues The user has a technical issue about an application triage Triage is needed

Comments

@choudham
Copy link
Contributor

choudham commented Nov 22, 2024

Name and Version

14.8.5

What architecture are you using?

amd64

What steps will reproduce the bug?

Deploy Minio Helm chart version 14.8.5

Provisioning job fails since the data drives are not up

image

Screenshot 2024-11-22 at 10.41.00 AM.png
Based on the above upstream change to address the race condition in helm chart we have 5 sec sleep but based on the observation our environment it took more time forit to stabilize (approximately 3 mins … see prometheus graph)

Are you using any custom parameters or values?

USER-SUPPLIED VALUES:
auth:
  rootPassword: XXXX
  rootUser: XXXX
defaultBuckets: ""
global:
  defaultStorageClass: default
image:
  registry: docker.io
  repository: bitnami/minio
  tag: 2024.8.3-debian-12-r1
metrics:
  enabled: true
  prometheusRule:
    enabled: true
  serviceMonitor:
    enabled: true
    labels:
      prometheus: default
      release: platform-monitoring
mode: distributed
persistence:
  size: 300Gi
podAnnotations:
  prometheus.io/path: /minio/v2/metrics
  prometheus.io/port: "9000"
  prometheus.io/scrape: "true"
provisioning:
  buckets:
  - anonymous: true
    lifecycle:
    - disabled: false
      expiry:
        days: 30
        noncurrentVersionDays: 0
      id: 30dRetention
    name: test-A
    versioning: false
    withLock: false
  - lifecycle:
    - disabled: false
      expiry:
        days: 30
        noncurrentVersionDays: 0
      id: 30dRetention
    name: test-B
    versioning: false
    withLock: false
  - lifecycle:
    - disabled: false
      expiry:
        days: 30
        noncurrentVersionDays: 0
      id: 30dRetention
    name: test-C
    versioning: false
    withLock: false
  - lifecycle:
    - disabled: false
      expiry:
        days: 30
        noncurrentVersionDays: 0
      id: 30dRetention
    name: tunnel
    quota:
      size: 30GiB
      type: set
    versioning: false
    withLock: false
  - lifecycle:
    - disabled: false
      expiry:
        days: 30
        noncurrentVersionDays: 0
      id: 30dRetention
    name: test123
    versioning: false
    withLock: false
  - anonymous: true
    name: test-D
    versioning: false
    withLock: false
  enabled: true
resourcesPreset: xlarge

What is the expected behavior?

The expected behavior is that the provisioning job should not fail.

Since sleep 5 is not enough, this should be parameterized and should be available as an option to be provided as a values.yaml

What do you see instead?

image

Additional information

https://github.com/bitnami/charts/blob/main/bitnami/minio/templates/provisioning-job.yaml#L149
Should be parameterized to be using a value in values.yaml

@choudham choudham added the tech-issues The user has a technical issue about an application label Nov 22, 2024
@github-actions github-actions bot added the triage Triage is needed label Nov 22, 2024
@choudham
Copy link
Contributor Author

choudham commented Nov 22, 2024

Error from job logs:

mc: <ERROR> Unable to set new lifecycle rules. Resource requested is unwritable, please reduce your request rate.

@carrodher
Copy link
Member

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

Copy link

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

@github-actions github-actions bot added the stale 15 days without activity label Dec 11, 2024
Copy link

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

@bitnami-bot bitnami-bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minio solved stale 15 days without activity tech-issues The user has a technical issue about an application triage Triage is needed
Projects
None yet
Development

No branches or pull requests

3 participants