Chart v9.0.1 breaks existing redis config #472
Labels
No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-chart#472
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Installing/upgrading to chart v9.0.1 with configuration working in v9.0.0 breaks redis with this in the log:
I'm using external GCP redis with this config:
Do I have to use redis-cluster instead of cache in v9.0.1? If so, what should it look like? I'm a bit confused.
Without
redis-cluster.enabled=true
you don't have any provider forcache
orsession
(as shown in the log above). You need one and if you don't want to useredis-cluster
you need to configure an external provider for these (e.g.memcache
).Hmmm... I'm confused. Are you saying that I need something like this? If not, can you show me an example of what the currently working config (in v9.0.0) should look like for v9.0.1?
An example for a
cache
config withredis-cluster
is in the upgrading notes.There's no change for the config between 9.0.0 and 9.0.1. I am not sure we're understanding each other right now 😅
The only thing you need for 9.0.0 is an explicit definition of
cache
and friends (again see the upgrading notes) due the bug shown in #356I'll release 9.0.2 in a few seconds, it's best to try with this one - but you will still need to configure the above mentioned values in your
values.yml
.My current Gitea config works in v9.0.0/1.19.4. If I update to (or install from scratch) v9.0.1/1.19.4 with no changes to the Gitea config, I get the error (PANIC: dial tcp 127.0.0.1:6379: connect: connection refused) as seen in the log above.
I don't know how to get the config used by Gitea when it can't start with v9.0.1 as the pod is in state CrashLoopBackOff. I would like to compare it with the config used when I install with the v9.0.0 chart.
Ah sorry, I think I misunderstood you. If you have an external working redis, you shouldn't set
redis-cluster.enabled=true
.In 9.0.1
session
has been set toredis
by default, I think this is where you're failing.Can you try definining
session
with your existingredis
instance as described in the Gitea docs?if you don't define
session
and also haveredis-cluster
disabled, it might be that a non-working configuration is written toapp.ini
. I need to check that.9.0.1 configured
session
by default withredis-cluster
- or expects a working external redis configuration. Which is missing in your case if you haven't set it explicitly before.@tobiasbp Did my suggestions help to solve your issue?
I'm afraid don't understand what you are suggesting :(
This is my current config with v9.0.0/1.19.4. If I change the chart to v9.0.1 (also new install) Redis breaks as sin in initial post.
These are the values used with the v9.0.0 chart:
Resulting /data/gitea/conf/app.ini from running pod:
I have the same issue, after upgrading to gitea-helm 9.x I can't run a simple gitea-instance. I don't need or want a redis-cluster, nor do I have a big enough instance to need something more than a sqlite-db.
https://docs.gitea.com/installation/install-with-docker
Gitea itself also doesn't need redis, nor an external database to work.
Are you saying it's impossible to use this helm-chart without external dependencies?
For context, I have tried the following (this is just the relevant parts):
It still looking for the service for the embedded redis-cluster.
@tobiasbp
You need to configure https://docs.gitea.com/next/administration/config-cheat-sheet#session-session with your existing redis installation.
And please use the latest release (9.0.3) and not 9.0.1.
I was able to get Gitea 1.19.4 running on chart v9.0.4 by adding these:
Should I still have these in the cache config??
cache
andsession
are two different settings, so yes - you need both. And this is unrelated to 1.19 or 1.20. Why do you want to go with 1.19?Before v9.x of the helm chart,
session
was not auto-configured but onlycache
.Because S3 storage appears to be broken in 1.2.x.
https://github.com/go-gitea/gitea/issues/25984
The chart will also work with 1.19 but you would need to issue a DB downgrade if you already upgraded to 1.20.