lunny/helm-chart
1
0
Fork 0
Code Issues 36 Pull Requests 14 Actions Packages Projects Releases 93 Wiki Activity

Run Gitea without redis-cluster #476

New Issue
Closed
opened 2023-07-22 08:58:37 +00:00 by pat-s · 9 comments
pat-s commented 2023-07-22 08:58:37 +00:00 (Migrated from gitea.com)
Copy Link

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 (Migrated from gitea.com)
Copy Link

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 commented 2023-07-22 12:09:14 +00:00 (Migrated from gitea.com)
Copy Link

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

I've added a minimal configuration example to the README as well.
jlec commented 2023-07-25 09:47:53 +00:00 (Migrated from gitea.com)
Copy Link

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 (Migrated from gitea.com)
Copy Link

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

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 (Migrated from gitea.com)
Copy Link

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 (Migrated from gitea.com)
Copy Link

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 (Migrated from gitea.com)
Copy Link

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 (Migrated from gitea.com)
Copy Link

Closing here for now as everyone seems happy :)

Closing here for now as everyone seems happy :)
pi3ch commented 2023-10-07 07:48:13 +00:00 (Migrated from gitea.com)
Copy Link

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`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
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 Label
kind/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#476
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?