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

Chartmuseum does not use redis correctly #1095

Open
CoderTH opened this issue Oct 16, 2024 · 1 comment · May be fixed by #1096
Open

Chartmuseum does not use redis correctly #1095

CoderTH opened this issue Oct 16, 2024 · 1 comment · May be fixed by #1096

Comments

@CoderTH
Copy link
Contributor

CoderTH commented Oct 16, 2024

If you are reporting a problem, please make sure the following information are provided:

Expected behavior and actual behavior:
A clear and concise description of what you expected to happen and what's the actual behavior. If applicable, add screenshots to help explain your problem.

I used harbor-operator to create a harbor instance and used redis_sentinel. What’s amazing is that I entered redis and wanted to manually obtain the relevant index.yaml. I found that there was no relevant data. After checking the configuration of Chartmuseum, I found that harbor-operator has There was a problem with its cache configuration, which resulted in redis not being actually used. Instead, the system cache was used after being downgraded by Chartmuseum.

Steps to reproduce the problem:
Please provide the steps to reproduce this problem.

  1. For multi-copy harbor, refresh the chart list and find that it keeps changing.
    image

  2. I suspected that it was a redis cache problem. I entered redis and switched to db3, and found that there were no logs.

image

  1. The result of manually parsing the Chartmuseum's configmap is:
allow.overwrite: true

auth:
  anonymous.get: false
cache: redis_sentinel
cache.redis:
  mastername: "mymaster"
  addr: "rfs-redis-test4.k-xxx-test-2.svc:26379"
  # password: setted through environment variable
  db: 3

context.path: ''

debug: false
depth: 1

disable:
  api: false
  delete: false
  force.overwrite: false
  metrics: false
  statefiles: false

index.limit: 0

log:
  health: false
  json: true

max:
  storage.objects: 0
  upload.size: 20971520

chart.post.form.field.name: chart
prov.post.form.field.name: prov%

  1. Check Chartmuseum's configuration of redis. The code is as shown in the figure
    image
cache: redis_sentinel
cache.redis:
  mastername: "mymaster"
  addr: "rfs-redis-test4.k-xxx-test-2.svc:26379"
  # password: setted through environment variable
  db: 3
  1. It seems that there is a problem with the key configured by redis. We should use ’cache.store: redis_sentinel‘ instead of 'cache: redis_sentinel' . I tried to modify the configmap, and after restarting, there was corresponding data in redis.
    image

Versions:
Please specify the versions of following systems.

  • harbor operator version: [x.y.z]
  • harbor version: [x.y.z]
  • kubernetes version: [x.y.z]
  • Any additional relevant versions such as CertManager

Additional context:

  • Harbor dependent services:
    • Context info of postgreSQL
    • Context info of Redis
    • Context info of storage
  • Log files: Collect logs and attach them here if have.
  • Kubernetes: How Kubernetes access was provided (what cloud provider, service-account configuration, ...).
@CoderTH
Copy link
Contributor Author

CoderTH commented Oct 16, 2024

we need update this code to 'cache.store'

image

@CoderTH CoderTH linked a pull request Oct 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant