Run Gitea without redis-cluster #476

New Issue

pat-s · 2023-07-22T08:58:37Z

pat-s commented

2023-07-22 08:58:37 +00:00

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):

    redis-cluster:
      enabled: false
    postgresql:
      enabled: false
    postgresql-ha:
      enabled: false
    gitea:
      config:
        cache:
          adapter: memory
        database:
          DB_TYPE: sqlite3
        session:
          provider: memory

It still looking for the service for the embedded redis-cluster.

Originally posted by @davralin in /gitea/helm-chart/issues/472#issuecomment-745501

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): ````yaml redis-cluster: enabled: false postgresql: enabled: false postgresql-ha: enabled: false gitea: config: cache: adapter: memory database: DB_TYPE: sqlite3 session: provider: memory ```` It still looking for the service for the embedded redis-cluster. _Originally posted by @davralin in /gitea/helm-chart/issues/472#issuecomment-745501_

pat-s commented

2023-07-22 09:01:53 +00:00

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.

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?

Gitea itself also doesn't need redis, nor an external database to work.

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.

Are you saying it's impossible to use this helm-chart without external dependencies?

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 enable redis-cluster).

> 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. 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? > Gitea itself also doesn't need redis, nor an external database to work. 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. > Are you saying it's impossible to use this helm-chart without external dependencies? 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 enable `redis-cluster`).

pat-s added the

kind

question

label 2023-07-22 09:02:08 +00:00

pat-s commented

2023-07-22 12:09:14 +00:00

I've added a minimal configuration example to the README as well.

jlec commented

2023-07-25 09:47:53 +00:00

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 enable redis-cluster).

Doesn't work here. Still getting the redis dependency.

2023/07/25 09:45:26 ...les/queue/manager.go:108:]() [E] Failed to create queue "notification-service": invalid leveldb connection string: "redis+cluster://:@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&"

> 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 enable `redis-cluster`). Doesn't work here. Still getting the redis dependency. > 2023/07/25 09:45:26 ...les/queue/manager.go:108:]() [E] Failed to create queue "notification-service": invalid leveldb connection string: "redis+cluster://:@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&"

jlec commented

2023-07-25 09:52:37 +00:00

Let me correct, the bug I am hitting is that switching from redis to level is not updating the app.ini. Manually cleaning hepls

pat-s commented

2023-07-25 17:36:48 +00:00

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.

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`.

a2geek commented

2023-08-05 16:36:13 +00:00

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.

gitea:
  config:
    session:
      PROVIDER: memory

ingress:
  enabled: true
  className: nginx
  hosts:
  - host: <my host name>
    paths:
    - path: /
      pathType: Prefix

# Using single instance of Postgres
postgresql:
  enabled: true

# Disable HA components
postgresql-ha:
  enabled: false
redis-cluster:
  enabled: false

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. :-)

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. ``` gitea: config: session: PROVIDER: memory ingress: enabled: true className: nginx hosts: - host: <my host name> paths: - path: / pathType: Prefix # Using single instance of Postgres postgresql: enabled: true # Disable HA components postgresql-ha: enabled: false redis-cluster: enabled: false ``` 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. :-)

pat-s commented

2023-08-06 08:24:30 +00:00

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).

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).

👍 1

pat-s commented

2023-08-13 19:55:24 +00:00

Closing here for now as everyone seems happy :)

pat-s closed this issue

2023-08-13 19:55:25 +00:00

pi3ch commented

2023-10-07 07:48:13 +00:00

If you are getting Failed to create queue "notification-service": invalid leveldb connection string try this in values.yaml

gitea:
  config:
    queue:
       TYPE: channel
       CONN_STR: memcache://gitea-memcached.<namespace>.svc.cluster.local:11211

Readme should be correct: type should be set to channel

If you are getting `Failed to create queue "notification-service": invalid leveldb connection string` try this in `values.yaml` ``` gitea: config: queue: TYPE: channel CONN_STR: memcache://gitea-memcached.<namespace>.svc.cluster.local:11211 ``` Readme should be correct: type should be set to `channel`

pat-s referenced this issue

2023-12-11 16:31:35 +00:00

Add config fallbacks for `session`, `cache` and `queue` when disabling redis-cluster #585

pat-s referenced this issue from a commit

2023-12-18 08:43:22 +00:00

Add config fallbacks for `session`, `cache` and `queue` when disabling redis-cluster (#585)

Sign in to join this conversation.