Chart v9.0.1 breaks existing redis config #472

New Issue

2023-07-19T12:41:21Z

tobiasbp commented

2023-07-19 12:41:21 +00:00

(Migrated from gitea.com)

Installing/upgrading to chart v9.0.1 with configuration working in v9.0.0 breaks redis with this in the log:

...
...
2023/07/19 11:11:42 ...eful/manager_unix.go:157:handleSignals() [W] [64b7c4e9] PID: 7. Background context for manager closed - context canceled - Shutting down...
2023/07/19 11:11:42 cmd/web.go:94:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused
	/go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20221220005550-e056dc379164/session.go:239 (0x175be57)
	/go/src/code.gitea.io/gitea/routers/web/web.go:111 (0x2444e64)
	/go/src/code.gitea.io/gitea/routers/init.go:191 (0x24af4aa)
	/go/src/code.gitea.io/gitea/cmd/web.go:180 (0x259c39d)
	/go/pkg/mod/github.com/urfave/cli@v1.22.10/app.go:524 (0x1dbe6af)
	/go/pkg/mod/github.com/urfave/cli@v1.22.10/command.go:173 (0x1dbf4fa)
	/go/pkg/mod/github.com/urfave/cli@v1.22.10/app.go:277 (0x1dbc1a6)
	/go/src/code.gitea.io/gitea/main.go:118 (0x25dbe6a)
	/usr/local/go/src/runtime/proc.go:250 (0x4444c6)
	/usr/local/go/src/runtime/asm_amd64.s:1598 (0x478fc0)

I'm using external GCP redis with this config:

    cache:
      ADAPTER: redis
      ENABLED: true
      HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s
...
...
redis-cluster:
  enabled: false

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.

Installing/upgrading to chart v9.0.1 with configuration working in v9.0.0 breaks redis with this in the log: ``` ... ... 2023/07/19 11:11:42 ...eful/manager_unix.go:157:handleSignals() [W] [64b7c4e9] PID: 7. Background context for manager closed - context canceled - Shutting down... 2023/07/19 11:11:42 cmd/web.go:94:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused /go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20221220005550-e056dc379164/session.go:239 (0x175be57) /go/src/code.gitea.io/gitea/routers/web/web.go:111 (0x2444e64) /go/src/code.gitea.io/gitea/routers/init.go:191 (0x24af4aa) /go/src/code.gitea.io/gitea/cmd/web.go:180 (0x259c39d) /go/pkg/mod/github.com/urfave/cli@v1.22.10/app.go:524 (0x1dbe6af) /go/pkg/mod/github.com/urfave/cli@v1.22.10/command.go:173 (0x1dbf4fa) /go/pkg/mod/github.com/urfave/cli@v1.22.10/app.go:277 (0x1dbc1a6) /go/src/code.gitea.io/gitea/main.go:118 (0x25dbe6a) /usr/local/go/src/runtime/proc.go:250 (0x4444c6) /usr/local/go/src/runtime/asm_amd64.s:1598 (0x478fc0) ``` I'm using external GCP _redis_ with this config: ``` cache: ADAPTER: redis ENABLED: true HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s ... ... redis-cluster: enabled: false ``` 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.

pat-s commented

2023-07-19 13:52:27 +00:00

(Migrated from gitea.com)

Without redis-cluster.enabled=true you don't have any provider for cache or session (as shown in the log above). You need one and if you don't want to use redis-cluster you need to configure an external provider for these (e.g. memcache).

Without `redis-cluster.enabled=true` you don't have any provider for `cache` or `session` (as shown in the log above). You need one and if you don't want to use `redis-cluster` you need to configure an external provider for these (e.g. `memcache`).

tobiasbp commented

2023-07-19 14:10:01 +00:00

(Migrated from gitea.com)

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?

    cache:
      ADAPTER: redis-cluster
      ENABLED: true
      HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s
...
...
redis-cluster:
  enabled: true

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? ``` cache: ADAPTER: redis-cluster ENABLED: true HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s ... ... redis-cluster: enabled: true ```

pat-s commented

2023-07-19 14:33:04 +00:00

(Migrated from gitea.com)

An example for a cache config with redis-cluster is in the upgrading notes.

config (in v9.0.0) should look like for v9.0.1?

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 #356

I'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.

An example for a `cache` config with `redis-cluster` is in the upgrading notes. > config (in v9.0.0) should look like for v9.0.1? 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 #356 I'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`.

tobiasbp commented

2023-07-19 15:10:22 +00:00

(Migrated from gitea.com)

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 😅

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.

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

pat-s commented

2023-07-19 15:43:51 +00:00

(Migrated from gitea.com)

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 to redis by default, I think this is where you're failing.
Can you try definining session with your existing redis instance as described in the Gitea docs?

if you don't define session and also have redis-cluster disabled, it might be that a non-working configuration is written to app.ini. I need to check that.

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 to `redis` by default, I think this is where you're failing. Can you try definining `session` with your existing `redis` instance as described in the Gitea docs? if you don't define `session` and also have `redis-cluster` disabled, it might be that a non-working configuration is written to `app.ini`. I need to check that.

pat-s commented

2023-07-19 19:59:18 +00:00

(Migrated from gitea.com)

9.0.1 configured session by default with redis-cluster - or expects a working external redis configuration. Which is missing in your case if you haven't set it explicitly before.

9.0.1 configured `session` by default with `redis-cluster` - or expects a working external redis configuration. Which is missing in your case if you haven't set it explicitly before.

pat-s commented

2023-07-21 09:59:51 +00:00

(Migrated from gitea.com)

@tobiasbp Did my suggestions help to solve your issue?

tobiasbp commented

2023-07-21 10:21:09 +00:00

(Migrated from gitea.com)

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:

helm -n git-backend get values gitea 

USER-SUPPLIED VALUES:
gitea:
  DOMAIN: ***
  ROOT_URL: ***
  admin:
    password: ***
  config:
    APP_NAME: Gitea (stg)
    RUN_MODE: dev
    admin:
      DEFAULT_EMAIL_NOTIFICATIONS: false
      DISABLE_REGULAR_ORG_CREATION: true
    cache:
      ADAPTER: redis
      ENABLED: true
      HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s
    database:
      DB_TYPE: postgres
      HOST: sql-proxy-gcloud-sqlproxy:5432
      NAME: gitea-db
      PASSWD: '***'
      SSL_MODE: disable
      USER: gitea-user
    metrics:
      ENABLED: true
    oauth2_client:
      ENABLE_AUTO_REGISTRATION: true
      OPENID_CONNECT_SCOPES: openid profile email
      REGISTER_EMAIL_CONFIRM: false
      UPDATE_AVATAR: true
      USERNAME: email
    repository:
      DEFAULT_PRIVATE: true
      DISABLE_MIGRATIONS: true
      DISABLE_STARS: true
      DISABLED_REPO_UNITS: repo.wiki, repo.ext_wiki, repo.packages, repo.projects,
        repo.issues, repo.ext_issues, repo.pulls
      FORCE_PRIVATE: true
    security:
      DISABLE_WEBHOOKS: true
      INSTALL_LOCK: true
    server:
      DISABLE_SSH: true
      LANDING_PAGE: login
      LFS_START_SERVER: true
      PROTOCOL: http
    service:
      DEFAULT_ALLOW_CREATE_ORGANIZATION: false
      DEFAULT_ORG_VISIBILITY: private
      DEFAULT_USER_VISIBILITY: private
      DISABLE_REGISTRATION: true
      REQUIRE_SIGNIN_VIEW: true
      SHOW_MILESTONES_DASHBOARD_PAGE: false
      explore:
        DISABLE_USERS_PAGE: true
        REQUIRE_SIGNIN_VIEW: true
    storage:
      MINIO_ACCESS_KEY_ID: ***
      MINIO_BUCKET: gitea-stg-aqrk
      MINIO_ENDPOINT: storage.googleapis.com
      MINIO_INSECURE_SKIP_VERIFY: false
      MINIO_SECRET_ACCESS_KEY: ***
      MINIO_USE_SSL: true
      SERVE_DIRECT: false
      STORAGE_TYPE: minio
  log:
    LEVEL: debug
image:
  tag: 1.19.4
ingress:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-production
  className: nginx
  enabled: true
  hosts:
  - host: ***
    paths:
    - path: /
      pathType: Prefix
  tls:
  - hosts:
    - ***
    secretName: git1-tls
memcached:
  enabled: false
persistence:
  claimName: data-gitea-0
  create: false
  enabled: false
  mount: true
  size: 20Gi
  storageClass: standard
postgresql:
  enabled: false
postgresql-ha:
  enabled: false
redis-cluster:
  enabled: false
resources:
  requests:
    cpu: 100m
    memory: 128Mi
strategy:
  type: Recreate

Resulting /data/gitea/conf/app.ini from running pod:

APP_NAME = Gitea (stg)
RUN_MODE = dev

[server]
LFS_JWT_SECRET   = ***
ROOT_URL         = ***
LFS_START_SERVER = true
ENABLE_PPROF     = false
LANDING_PAGE     = login
SSH_PORT         = 22
APP_DATA_PATH    = /data
SSH_LISTEN_PORT  = 2222
PROTOCOL         = http
HTTP_PORT        = 3000
START_SSH_SERVER = true
DISABLE_SSH      = true
SSH_DOMAIN       = ***
DOMAIN           = ***

[database]
NAME     = gitea-db
SSL_MODE = disable
DB_TYPE  = postgres
HOST     = sql-proxy-gcloud-sqlproxy:5432
USER     = gitea-user
PASSWD   = ***

[service]
SHOW_MILESTONES_DASHBOARD_PAGE    = false
REQUIRE_SIGNIN_VIEW               = true
DISABLE_REGISTRATION              = true
EXPLORE                           = map[DISABLE_USERS_PAGE:true REQUIRE_SIGNIN_VIEW:true]
DEFAULT_ORG_VISIBILITY            = private
DEFAULT_USER_VISIBILITY           = private
DEFAULT_ALLOW_CREATE_ORGANIZATION = false

[repository]
DISABLE_STARS       = true
DISABLE_MIGRATIONS  = true
FORCE_PRIVATE       = true
ROOT                = /data/git/gitea-repositories
DISABLED_REPO_UNITS = repo.wiki, repo.ext_wiki, repo.packages, repo.projects, repo.issues, repo.ext_issues, repo.pulls
DEFAULT_PRIVATE     = true

[oauth2_client]
REGISTER_EMAIL_CONFIRM   = false
USERNAME                 = email
UPDATE_AVATAR            = true
ENABLE_AUTO_REGISTRATION = true
OPENID_CONNECT_SCOPES    = openid profile email

[storage]
MINIO_USE_SSL              = true
MINIO_ENDPOINT             = storage.googleapis.com
STORAGE_TYPE               = minio
SERVE_DIRECT               = false
MINIO_BUCKET               = gitea-stg-aqrk
MINIO_SECRET_ACCESS_KEY    = ***
MINIO_ACCESS_KEY_ID        = ***
MINIO_INSECURE_SKIP_VERIFY = false

[security]
DISABLE_WEBHOOKS = true
INTERNAL_TOKEN   = ***
SECRET_KEY       = ***
INSTALL_LOCK     = true

[cache]
HOST    = redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s
ENABLED = true
ADAPTER = redis

[admin]
DISABLE_REGULAR_ORG_CREATION = true
DEFAULT_EMAIL_NOTIFICATIONS  = false

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: <details> ``` helm -n git-backend get values gitea USER-SUPPLIED VALUES: gitea: DOMAIN: *** ROOT_URL: *** admin: password: *** config: APP_NAME: Gitea (stg) RUN_MODE: dev admin: DEFAULT_EMAIL_NOTIFICATIONS: false DISABLE_REGULAR_ORG_CREATION: true cache: ADAPTER: redis ENABLED: true HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s database: DB_TYPE: postgres HOST: sql-proxy-gcloud-sqlproxy:5432 NAME: gitea-db PASSWD: '***' SSL_MODE: disable USER: gitea-user metrics: ENABLED: true oauth2_client: ENABLE_AUTO_REGISTRATION: true OPENID_CONNECT_SCOPES: openid profile email REGISTER_EMAIL_CONFIRM: false UPDATE_AVATAR: true USERNAME: email repository: DEFAULT_PRIVATE: true DISABLE_MIGRATIONS: true DISABLE_STARS: true DISABLED_REPO_UNITS: repo.wiki, repo.ext_wiki, repo.packages, repo.projects, repo.issues, repo.ext_issues, repo.pulls FORCE_PRIVATE: true security: DISABLE_WEBHOOKS: true INSTALL_LOCK: true server: DISABLE_SSH: true LANDING_PAGE: login LFS_START_SERVER: true PROTOCOL: http service: DEFAULT_ALLOW_CREATE_ORGANIZATION: false DEFAULT_ORG_VISIBILITY: private DEFAULT_USER_VISIBILITY: private DISABLE_REGISTRATION: true REQUIRE_SIGNIN_VIEW: true SHOW_MILESTONES_DASHBOARD_PAGE: false explore: DISABLE_USERS_PAGE: true REQUIRE_SIGNIN_VIEW: true storage: MINIO_ACCESS_KEY_ID: *** MINIO_BUCKET: gitea-stg-aqrk MINIO_ENDPOINT: storage.googleapis.com MINIO_INSECURE_SKIP_VERIFY: false MINIO_SECRET_ACCESS_KEY: *** MINIO_USE_SSL: true SERVE_DIRECT: false STORAGE_TYPE: minio log: LEVEL: debug image: tag: 1.19.4 ingress: annotations: cert-manager.io/cluster-issuer: letsencrypt-production className: nginx enabled: true hosts: - host: *** paths: - path: / pathType: Prefix tls: - hosts: - *** secretName: git1-tls memcached: enabled: false persistence: claimName: data-gitea-0 create: false enabled: false mount: true size: 20Gi storageClass: standard postgresql: enabled: false postgresql-ha: enabled: false redis-cluster: enabled: false resources: requests: cpu: 100m memory: 128Mi strategy: type: Recreate ``` </details> Resulting _/data/gitea/conf/app.ini_ from running pod: <details> ``` APP_NAME = Gitea (stg) RUN_MODE = dev [server] LFS_JWT_SECRET = *** ROOT_URL = *** LFS_START_SERVER = true ENABLE_PPROF = false LANDING_PAGE = login SSH_PORT = 22 APP_DATA_PATH = /data SSH_LISTEN_PORT = 2222 PROTOCOL = http HTTP_PORT = 3000 START_SSH_SERVER = true DISABLE_SSH = true SSH_DOMAIN = *** DOMAIN = *** [database] NAME = gitea-db SSL_MODE = disable DB_TYPE = postgres HOST = sql-proxy-gcloud-sqlproxy:5432 USER = gitea-user PASSWD = *** [service] SHOW_MILESTONES_DASHBOARD_PAGE = false REQUIRE_SIGNIN_VIEW = true DISABLE_REGISTRATION = true EXPLORE = map[DISABLE_USERS_PAGE:true REQUIRE_SIGNIN_VIEW:true] DEFAULT_ORG_VISIBILITY = private DEFAULT_USER_VISIBILITY = private DEFAULT_ALLOW_CREATE_ORGANIZATION = false [repository] DISABLE_STARS = true DISABLE_MIGRATIONS = true FORCE_PRIVATE = true ROOT = /data/git/gitea-repositories DISABLED_REPO_UNITS = repo.wiki, repo.ext_wiki, repo.packages, repo.projects, repo.issues, repo.ext_issues, repo.pulls DEFAULT_PRIVATE = true [oauth2_client] REGISTER_EMAIL_CONFIRM = false USERNAME = email UPDATE_AVATAR = true ENABLE_AUTO_REGISTRATION = true OPENID_CONNECT_SCOPES = openid profile email [storage] MINIO_USE_SSL = true MINIO_ENDPOINT = storage.googleapis.com STORAGE_TYPE = minio SERVE_DIRECT = false MINIO_BUCKET = gitea-stg-aqrk MINIO_SECRET_ACCESS_KEY = *** MINIO_ACCESS_KEY_ID = *** MINIO_INSECURE_SKIP_VERIFY = false [security] DISABLE_WEBHOOKS = true INTERNAL_TOKEN = *** SECRET_KEY = *** INSTALL_LOCK = true [cache] HOST = redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s ENABLED = true ADAPTER = redis [admin] DISABLE_REGULAR_ORG_CREATION = true DEFAULT_EMAIL_NOTIFICATIONS = false ``` </details>

Ghost commented

2023-07-21 21:03:27 +00:00

(Migrated from gitea.com)

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.

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.

pat-s commented

2023-07-22 08:57:25 +00:00

(Migrated from gitea.com)

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

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

tobiasbp commented

2023-07-25 15:20:00 +00:00

(Migrated from gitea.com)

I was able to get Gitea 1.19.4 running on chart v9.0.4 by adding these:

gitea.config.session.PROVIDER: redis
gitea.config.session.PROVIDER_CONFIG: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s

Should I still have these in the cache config??

gitea.config.cache.ADAPTER: redis
gitea.config.cache.HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s

I was able to get Gitea 1.19.4 running on chart v9.0.4 by adding these: ``` gitea.config.session.PROVIDER: redis gitea.config.session.PROVIDER_CONFIG: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s ``` Should I still have these in the cache config?? ``` gitea.config.cache.ADAPTER: redis gitea.config.cache.HOST: redis://redis-1.source-access.private:6379/0?pool_size=100&idle_timeout=180s ```

pat-s commented

2023-07-25 17:42:45 +00:00

(Migrated from gitea.com)

cache and session 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 only cache.

`cache` and `session` 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 only `cache`.

tobiasbp commented

2023-08-02 09:43:35 +00:00

(Migrated from gitea.com)