Run Gitea without redis-cluster #476
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?
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.
Originally posted by @davralin in /gitea/helm-chart/issues/472#issuecomment-745501
On a higher level I would argue that k8s might not be the best installation method then. Why not use docker or a binary install instead?
It doesn't but the helm chart aims to make it easier to achieve a HA setup for production use rather than a toy installation.
It's not but you need to change the config appropriately. On the first look it seems that need to set
queue.type=level
as otherwise a redis config is expected (which is auto-generated when you enableredis-cluster
).I've added a minimal configuration example to the README as well.
Doesn't work here. Still getting the redis dependency.
Let me correct, the bug I am hitting is that switching from redis to level is not updating the app.ini. Manually cleaning hepls
See #365. You need to manually override all previous values explicitly (or remove them manually). In your case this would have been
queue.CONN_STR
.I was going to write in with the a similar comment. But, I did find that if you leave out the level definition all together, it does seem fine. Same issue in that I needed to provide the CONN_STR for the level db... but I don't really have a clue what that is and a 5 minute search through the Gitea code didn't help me with the default, so I experimented.
This is a cleaned up version of my simplified config.
And to the rest of the discussion, as a newbie in the Kubernetes world, I definitely want to "simplify" installations if I can, and Helm charts seem the way to go. Obviously, my preference is to use one created by the people who actually write the software! Home use, yes. "Toy" not really, but also definitely not Enterprise either. Small office. :-)
We currently have one default setup which auto-configures everything - which relies on redis-cluster. If using other components there's no guarantee that all fields are auto-populated.
We've made the (most likely) a bit unpopular approach to focus more on a HA setup than a minimal one here. Reason for that being that if you host it on k8s, it's more likely to be a larger instance or for production use in a company setting.
It doesn't have to be, but more likely is.
Also there hasn't been any HA setup so far out there and the need became larger.
For personal use I would rather go with docker directly or a host install. k8s is of course possible but you have to switch to minimal, non-HA dependencies. And k8s works best if a deployment runs in HA - otherwise you are not really using the power of k8s.
@a2geek You might want to use memcache for session, cache and queue - otherwise you might get into trouble at some point when setting these to
memory
(even though I never tried to push that).Closing here for now as everyone seems happy :)
If you are getting
Failed to create queue "notification-service": invalid leveldb connection string
try this invalues.yaml
Readme should be correct: type should be set to
channel