Migration to 9.0.0 not updating cache.ADAPTER from memcache to redis-cluster #468

New Issue

Closed

opened 2023-07-18 12:07:49 +00:00 by mmalyska · 16 comments

mmalyska commented 2023-07-18 12:07:49 +00:00

Contributor

Copy Link

Hello, after upgrade from 8.x.x to 9.0.0 I have problems when I've removed memcache and switched to redis-cluster.

This is the log from init-app-ini

  ...Initial secrets generated

Processing inlines...
cache
  + 'ADAPTER'
  + 'ENABLED'
  + 'HOST'
repository
  + 'ROOT'
[ini root]
  + 'APP_NAME'
  + 'RUN_MODE'
  + 'RUN_USER'
metrics
  + 'ENABLED'
cors
  + 'ALLOW_CREDENTIALS'
  + 'ALLOW_DOMAIN'
  + 'ALLOW_SUBDOMAIN'
  + 'ENABLED'
  + 'MAX_AGE'
  + 'METHODS'
  + 'SCHEME'
database
  + 'DB_TYPE'
  + 'HOST'
  + 'NAME'
  + 'SSL_MODE'
queue
  + 'CONN_STR'
  + 'TYPE'
service
  + 'DEFAULT_ALLOW_CREATE_ORGANIZATION'
  + 'DEFAULT_KEEP_EMAIL_PRIVATE'
  + 'DISABLE_REGISTRATION'
  + 'ENABLE_CAPTCHA'
security
  + 'INSTALL_LOCK'
server
  + 'APP_DATA_PATH'
  + 'DOMAIN'
  + 'ENABLE_PPROF'
  + 'HTTP_PORT'
  + 'LFS_START_SERVER'
  + 'PROTOCOL'
  + 'ROOT_URL'
  + 'SSH_DOMAIN'
  + 'SSH_LISTEN_PORT'
  + 'SSH_PORT'
  + 'START_SSH_SERVER'


Reloading preset envs...
+ 'GITEADB_CNPG_RO_PORT_5432_TCP_PORT'
+ 'GITEADB_CNPG_RW_SERVICE_HOST'
+ 'GITEADB_CNPG_RW_PORT_5432_TCP_PROTO'
+ 'GITEADB_CNPG_R_SERVICE_PORT_POSTGRES'
+ 'GITEA__database__DB_TYPE'
+ 'GITEADB_CNPG_RW_PORT_5432_TCP_PORT'
+ 'GITEA_APP_INI'
+ 'GITEADB_CNPG_R_PORT_5432_TCP'
+ 'GITEA_REDIS_CLUSTER_PORT_6379_TCP'
+ 'GITEADB_CNPG_R_PORT'
+ 'GITEADB_CNPG_R_PORT_5432_TCP_ADDR'
+ 'GITEA_WORK_DIR'
+ 'GITEADB_CNPG_RO_PORT_5432_TCP_ADDR'
+ 'GITEA_REDIS_CLUSTER_PORT'
+ 'GITEADB_CNPG_RO_PORT_5432_TCP_PROTO'
+ 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_ADDR'
+ 'GITEADB_CNPG_RW_PORT_5432_TCP'
+ 'GITEADB_CNPG_RO_PORT_5432_TCP'
+ 'GITEA_REDIS_CLUSTER_SERVICE_HOST'
+ 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_PROTO'
+ 'GITEADB_CNPG_RO_SERVICE_HOST'
+ 'GITEADB_CNPG_RO_PORT'
+ 'GITEA_REDIS_CLUSTER_SERVICE_PORT'
+ 'GITEA__database__USER'
+ 'GITEADB_CNPG_R_SERVICE_HOST'
+ 'GITEA_TEMP'
+ 'GITEA_REDIS_CLUSTER_SERVICE_PORT_TCP_REDIS'
+ 'GITEADB_CNPG_R_SERVICE_PORT'
+ 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_PORT'
+ 'GITEADB_CNPG_RO_SERVICE_PORT_POSTGRES'
+ 'GITEADB_CNPG_RO_SERVICE_PORT'
+ 'GITEADB_CNPG_R_PORT_5432_TCP_PROTO'
+ 'GITEADB_CNPG_RW_PORT_5432_TCP_ADDR'
+ 'GITEADB_CNPG_RW_SERVICE_PORT'
+ 'GITEADB_CNPG_R_PORT_5432_TCP_PORT'
+ 'GITEA__database__PASSWD'
+ 'GITEADB_CNPG_RW_PORT'
+ 'GITEADB_CNPG_RW_SERVICE_PORT_POSTGRES'
+ 'GITEA_CUSTOM'
=== All configuration sources loaded ===

An app.ini file already exists. To prevent overwriting secret keys, these settings are dropped and remain unchanged:
- security.INTERNAL_TOKEN
- security.SECRET_KEY
- oauth2.JWT_SECRET
- server.LFS_JWT_SECRET

But the values are not updated in file

init-file-generated

RUN_MODE = prod
RUN_USER = git
APP_NAME = Gitea: Git with a cup of tea
WORK_PATH = /data

[service]
ENABLE_CAPTCHA = true
DEFAULT_ALLOW_CREATE_ORGANIZATION = false
DISABLE_REGISTRATION = true
DEFAULT_KEEP_EMAIL_PRIVATE = true

[server]
LFS_JWT_SECRET = XX
APP_DATA_PATH = /data
SSH_DOMAIN = git.XX
PROTOCOL = http
HTTP_PORT = 3000
ROOT_URL = https://git.XX/
SSH_LISTEN_PORT = 2222
LFS_START_SERVER = true
SSH_PORT = 22
ENABLE_PPROF = false
DOMAIN = git.XX
START_SSH_SERVER = true

[cors]
ALLOW_SUBDOMAIN = true
ALLOW_CREDENTIALS = false
ALLOW_DOMAIN = XX
ENABLED = true
MAX_AGE = 10m
METHODS = GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS
SCHEME = https

[database]
DB_TYPE = postgres
HOST = giteadb-cnpg-rw
PASSWD = XX
NAME = app
USER = app
SSL_MODE = require

[cache]
ENABLED = true
HOST = gitea-memcached.gitea.svc.cluster.local:11211
ADAPTER = memcache

[repository]
ROOT = /data/git/gitea-repositories

[security]
INSTALL_LOCK = true
SECRET_KEY = XX
INTERNAL_TOKEN = XX

[metrics]
ENABLED = false

[oauth2]
JWT_SECRET = XX

Those are my values of chart

values.yaml

image:
  repository: gitea/gitea
  tag: 1.20.0
  pullPolicy: IfNotPresent
  rootless: true # only possible when running 1.14 or later
podSecurityContext:
  fsGroup: 1000
gitea:
  config:
    APP_NAME: "Gitea: Git with a cup of tea"
    RUN_MODE: "prod"
    RUN_USER: "git"
    server:
      APP_DATA_PATH: "/data"
      DOMAIN: git.<secret:private-domain>
      SSH_DOMAIN: git.<secret:private-domain>
      HTTP_PORT: 3000
      ROOT_URL: https://git.<secret:private-domain>/
      LFS_START_SERVER: true
    database:
      DB_TYPE: postgres
      HOST: giteadb-cnpg-rw
      NAME: app
      SSL_MODE: require
    service:
      DISABLE_REGISTRATION: true
      ENABLE_CAPTCHA: true
      DEFAULT_KEEP_EMAIL_PRIVATE: true
      DEFAULT_ALLOW_CREATE_ORGANIZATION: false
    cors:
      ENABLED: true
      SCHEME: https
      ALLOW_DOMAIN: <secret:private-domain>
      ALLOW_SUBDOMAIN: true
      METHODS: "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS"
      MAX_AGE: 10m
      ALLOW_CREDENTIALS: false
postgresql:
  enabled: false
redis-cluster:
  enabled: true
postgresql-ha:
  enabled: false
persistence:
  enabled: true
  claimName: gitea-data
  accessModes:
    - ReadWriteMany
  storageClass: ceph-filesystem
replicaCount: 1
deployment:
  env:
    - name: GITEA__database__DB_TYPE
      value: postgres
    - name: GITEA__database__USER
      valueFrom:
        secretKeyRef:
          name: giteadb-cnpg-app
          key: username
    - name: GITEA__database__PASSWD
      valueFrom:
        secretKeyRef:
          name: giteadb-cnpg-app
          key: password

Hello, after upgrade from `8.x.x` to `9.0.0` I have problems when I've removed `memcache` and switched to `redis-cluster`. <details> <summary>This is the log from init-app-ini</summary> ``` ...Initial secrets generated Processing inlines... cache + 'ADAPTER' + 'ENABLED' + 'HOST' repository + 'ROOT' [ini root] + 'APP_NAME' + 'RUN_MODE' + 'RUN_USER' metrics + 'ENABLED' cors + 'ALLOW_CREDENTIALS' + 'ALLOW_DOMAIN' + 'ALLOW_SUBDOMAIN' + 'ENABLED' + 'MAX_AGE' + 'METHODS' + 'SCHEME' database + 'DB_TYPE' + 'HOST' + 'NAME' + 'SSL_MODE' queue + 'CONN_STR' + 'TYPE' service + 'DEFAULT_ALLOW_CREATE_ORGANIZATION' + 'DEFAULT_KEEP_EMAIL_PRIVATE' + 'DISABLE_REGISTRATION' + 'ENABLE_CAPTCHA' security + 'INSTALL_LOCK' server + 'APP_DATA_PATH' + 'DOMAIN' + 'ENABLE_PPROF' + 'HTTP_PORT' + 'LFS_START_SERVER' + 'PROTOCOL' + 'ROOT_URL' + 'SSH_DOMAIN' + 'SSH_LISTEN_PORT' + 'SSH_PORT' + 'START_SSH_SERVER' Reloading preset envs... + 'GITEADB_CNPG_RO_PORT_5432_TCP_PORT' + 'GITEADB_CNPG_RW_SERVICE_HOST' + 'GITEADB_CNPG_RW_PORT_5432_TCP_PROTO' + 'GITEADB_CNPG_R_SERVICE_PORT_POSTGRES' + 'GITEA__database__DB_TYPE' + 'GITEADB_CNPG_RW_PORT_5432_TCP_PORT' + 'GITEA_APP_INI' + 'GITEADB_CNPG_R_PORT_5432_TCP' + 'GITEA_REDIS_CLUSTER_PORT_6379_TCP' + 'GITEADB_CNPG_R_PORT' + 'GITEADB_CNPG_R_PORT_5432_TCP_ADDR' + 'GITEA_WORK_DIR' + 'GITEADB_CNPG_RO_PORT_5432_TCP_ADDR' + 'GITEA_REDIS_CLUSTER_PORT' + 'GITEADB_CNPG_RO_PORT_5432_TCP_PROTO' + 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_ADDR' + 'GITEADB_CNPG_RW_PORT_5432_TCP' + 'GITEADB_CNPG_RO_PORT_5432_TCP' + 'GITEA_REDIS_CLUSTER_SERVICE_HOST' + 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_PROTO' + 'GITEADB_CNPG_RO_SERVICE_HOST' + 'GITEADB_CNPG_RO_PORT' + 'GITEA_REDIS_CLUSTER_SERVICE_PORT' + 'GITEA__database__USER' + 'GITEADB_CNPG_R_SERVICE_HOST' + 'GITEA_TEMP' + 'GITEA_REDIS_CLUSTER_SERVICE_PORT_TCP_REDIS' + 'GITEADB_CNPG_R_SERVICE_PORT' + 'GITEA_REDIS_CLUSTER_PORT_6379_TCP_PORT' + 'GITEADB_CNPG_RO_SERVICE_PORT_POSTGRES' + 'GITEADB_CNPG_RO_SERVICE_PORT' + 'GITEADB_CNPG_R_PORT_5432_TCP_PROTO' + 'GITEADB_CNPG_RW_PORT_5432_TCP_ADDR' + 'GITEADB_CNPG_RW_SERVICE_PORT' + 'GITEADB_CNPG_R_PORT_5432_TCP_PORT' + 'GITEA__database__PASSWD' + 'GITEADB_CNPG_RW_PORT' + 'GITEADB_CNPG_RW_SERVICE_PORT_POSTGRES' + 'GITEA_CUSTOM' === All configuration sources loaded === An app.ini file already exists. To prevent overwriting secret keys, these settings are dropped and remain unchanged: - security.INTERNAL_TOKEN - security.SECRET_KEY - oauth2.JWT_SECRET - server.LFS_JWT_SECRET ``` </details> But the values are not updated in file <details> <summary>init-file-generated</summary> ``` RUN_MODE = prod RUN_USER = git APP_NAME = Gitea: Git with a cup of tea WORK_PATH = /data [service] ENABLE_CAPTCHA = true DEFAULT_ALLOW_CREATE_ORGANIZATION = false DISABLE_REGISTRATION = true DEFAULT_KEEP_EMAIL_PRIVATE = true [server] LFS_JWT_SECRET = XX APP_DATA_PATH = /data SSH_DOMAIN = git.XX PROTOCOL = http HTTP_PORT = 3000 ROOT_URL = https://git.XX/ SSH_LISTEN_PORT = 2222 LFS_START_SERVER = true SSH_PORT = 22 ENABLE_PPROF = false DOMAIN = git.XX START_SSH_SERVER = true [cors] ALLOW_SUBDOMAIN = true ALLOW_CREDENTIALS = false ALLOW_DOMAIN = XX ENABLED = true MAX_AGE = 10m METHODS = GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS SCHEME = https [database] DB_TYPE = postgres HOST = giteadb-cnpg-rw PASSWD = XX NAME = app USER = app SSL_MODE = require [cache] ENABLED = true HOST = gitea-memcached.gitea.svc.cluster.local:11211 ADAPTER = memcache [repository] ROOT = /data/git/gitea-repositories [security] INSTALL_LOCK = true SECRET_KEY = XX INTERNAL_TOKEN = XX [metrics] ENABLED = false [oauth2] JWT_SECRET = XX ``` </details> Those are my values of chart <details> <summary>values.yaml</summary> ``` image: repository: gitea/gitea tag: 1.20.0 pullPolicy: IfNotPresent rootless: true # only possible when running 1.14 or later podSecurityContext: fsGroup: 1000 gitea: config: APP_NAME: "Gitea: Git with a cup of tea" RUN_MODE: "prod" RUN_USER: "git" server: APP_DATA_PATH: "/data" DOMAIN: git.<secret:private-domain> SSH_DOMAIN: git.<secret:private-domain> HTTP_PORT: 3000 ROOT_URL: https://git.<secret:private-domain>/ LFS_START_SERVER: true database: DB_TYPE: postgres HOST: giteadb-cnpg-rw NAME: app SSL_MODE: require service: DISABLE_REGISTRATION: true ENABLE_CAPTCHA: true DEFAULT_KEEP_EMAIL_PRIVATE: true DEFAULT_ALLOW_CREATE_ORGANIZATION: false cors: ENABLED: true SCHEME: https ALLOW_DOMAIN: <secret:private-domain> ALLOW_SUBDOMAIN: true METHODS: "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS" MAX_AGE: 10m ALLOW_CREDENTIALS: false postgresql: enabled: false redis-cluster: enabled: true postgresql-ha: enabled: false persistence: enabled: true claimName: gitea-data accessModes: - ReadWriteMany storageClass: ceph-filesystem replicaCount: 1 deployment: env: - name: GITEA__database__DB_TYPE value: postgres - name: GITEA__database__USER valueFrom: secretKeyRef: name: giteadb-cnpg-app key: username - name: GITEA__database__PASSWD valueFrom: secretKeyRef: name: giteadb-cnpg-app key: password ``` </details>

viceice commented 2023-07-18 13:24:50 +00:00

Contributor

Copy Link

seeing same issue, need to maually update the app.ini 😕

seeing same issue, need to maually update the app.ini 😕

justusbunsi commented 2023-07-18 15:49:42 +00:00

Member

Copy Link

Sounds like either #453 or the generic one #356.

Sounds like either #453 or the generic one #356.

pat-s commented 2023-07-18 16:12:32 +00:00

Member

Copy Link

This is due to #356 and friends.

I think it should work fine for new installations but existing ones might need to set the following options explicitly until the above is fixed:

    session:
      PROVIDER: redis
      PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      
    cache:
      ENABLED: true
      ADAPTER: redis
      HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      
    queue:
      TYPE: redis
      CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&

Does this help to resolve the issue?

This is due to #356 and friends. I think it should work fine for new installations but existing ones might need to set the following options explicitly until the above is fixed: ```yml session: PROVIDER: redis PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& cache: ENABLED: true ADAPTER: redis HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& queue: TYPE: redis CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& ``` Does this help to resolve the issue?

pat-s added the

kind

bug

priority

critical

labels 2023-07-18 17:35:47 +00:00

smolinari commented 2023-07-19 07:02:19 +00:00

Copy Link

Sorry to barge into this thread, but I'm also having a minor issue with the new redis setup.

I love it that we can now use our own redis setup for the cache, saving the no longer needed memcached pod. However, in our situation, our redis deployment has authentication set up and we'd like to be able to restrict any redis clients/users to a certain keyspace.

https://redis.io/docs/manual/keyspace/
https://redis.io/docs/management/security/acl/#key-permissions

It would be nice to be able to either know what Gitea uses for a keyspace or even be able to set the keyspace being used ourselves.

If this sounds viable, should I start a new suggestion issue about it? Or at a minimum, can it be documented what keyspace/ key schema gitea uses?

Edit: I know I could go searching through the code to find the keyspace myself, but I'm a bit time restricted at the moment. Sorry.

Scott

Sorry to barge into this thread, but I'm also having a minor issue with the new redis setup. I love it that we can now use our own redis setup for the cache, saving the no longer needed memcached pod. However, in our situation, our redis deployment has authentication set up and we'd like to be able to restrict any redis clients/users to a certain keyspace. https://redis.io/docs/manual/keyspace/ https://redis.io/docs/management/security/acl/#key-permissions It would be nice to be able to either know what Gitea uses for a keyspace or even be able to set the keyspace being used ourselves. If this sounds viable, should I start a new suggestion issue about it? Or at a minimum, can it be documented what keyspace/ key schema gitea uses? Edit: I know I could go searching through the code to find the keyspace myself, but I'm a bit time restricted at the moment. Sorry. Scott

pat-s commented 2023-07-19 07:34:23 +00:00

Member

Copy Link

@smolinari Redis support has been there before this release, for both cluster and non-cluster versions.

I am not familiar with Redis auth but the chart shouldn't limit you here. Maybe it works via additional options in the connection string as documented here?

I think your request might be better suited in upstream Gitea than here as the helm chart does not anything special to redis auth, i.e. the change in v9.0.0 just switched the default to redis-cluster but all configuration options WRT to redis are the same as before.

Happy to document it but I think the information should then also go to the official Gitea docs and not the helm docs. Let's move this discussion to a new issue as this issue is actually about something else.

@smolinari Redis support has been there before this release, for both cluster and non-cluster versions. I am not familiar with Redis auth but the chart shouldn't limit you here. Maybe it works via additional options in the connection string as documented [here](https://docs.gitea.com/next/administration/config-cheat-sheet?_highlight=redis#queue-queue-and-queue)? I think your request might be better suited in upstream Gitea than here as the helm chart does not anything special to redis auth, i.e. the change in v9.0.0 just switched the default to `redis-cluster` but all configuration options WRT to redis are the same as before. Happy to document it but I think the information should then also go to the official Gitea docs and not the helm docs. Let's move this discussion to a new issue as this issue is actually about something else.

mmalyska commented 2023-07-19 07:41:20 +00:00

Author

Contributor

Copy Link

@pat-s the provider and adapter are wrong in 75893ad9c6. They should be redis-cluster instead of redis, no?

@pat-s the `provider` and `adapter` are wrong in https://gitea.com/gitea/helm-chart/commit/75893ad9c670cd2dee5e6ac041fd419be935cb1d. They should be `redis-cluster` instead of `redis`, no?

pat-s commented 2023-07-19 07:58:03 +00:00

Member

Copy Link

Correct, but for some reasons redis also seems to work as long as the connection string is using redis+cluster. I would need to look into it in more detail. queue also has no redis-cluster key but probably should have one.

Thanks for mentioning! 19841604f7

Correct, but for some reasons `redis` also seems to work as long as the connection string is using `redis+cluster`. I would need to look into it in more detail. `queue` also has no `redis-cluster` key but probably should have one. Thanks for mentioning! 19841604f76f17e4334611b7933bf0ded062f061

mmalyska commented 2023-07-19 08:10:23 +00:00

Author

Contributor

Copy Link

This is due to #356 and friends.

I think it should work fine for new installations but existing ones might need to set the following options explicitly until the above is fixed:

    session:
      PROVIDER: redis
      PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      
    cache:
      ENABLED: true
      ADAPTER: redis
      HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      
    queue:
      TYPE: redis
      CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>v.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&

Does this help to resolve the issue?

I don't know why, when I add those values in values.yaml the file app.ini is still not updated :/

> This is due to #356 and friends. > > I think it should work fine for new installations but existing ones might need to set the following options explicitly until the above is fixed: > > > ```yml > session: > PROVIDER: redis > PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& > > cache: > ENABLED: true > ADAPTER: redis > HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& > > queue: > TYPE: redis > CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>v.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& > > ``` > > Does this help to resolve the issue? I don't know why, when I add those values in `values.yaml` the file `app.ini` is still not updated :/

pat-s commented 2023-07-19 08:26:56 +00:00

Member

Copy Link

Do you have them below gitea.config?

Do you have them below `gitea.config`?

viceice commented 2023-07-19 08:28:59 +00:00

Contributor

Copy Link

Yes, that didn't help. the gitea-inline-config secret is updated, but the app.ini doesn't get updated. i had to manually do that for existing changed values.

eg, i'v switched issue indexer to meilisearch in gitea.config in values.yml, but that change wasn't passed to the app.ini

Yes, that didn't help. the `gitea-inline-config` secret is updated, but the `app.ini` doesn't get updated. i had to manually do that for existing changed values. eg, i'v switched issue indexer to meilisearch in `gitea.config` in `values.yml`, but that change wasn't passed to the `app.ini`

mmalyska commented 2023-07-19 08:39:13 +00:00

Author

Contributor

Copy Link

Do you have them below gitea.config?

Yes, this looks like this

  image:
    repository: gitea/gitea
    tag: 1.20.0
    pullPolicy: IfNotPresent
    rootless: true # only possible when running 1.14 or later
  podSecurityContext:
    fsGroup: 1000
  gitea:
    config:
      APP_NAME: "Gitea: Git with a cup of tea"
      RUN_MODE: "prod"
      RUN_USER: "git"
      server:
        APP_DATA_PATH: "/data"
        DOMAIN: git.<secret:private-domain>
        SSH_DOMAIN: git.<secret:private-domain>
        HTTP_PORT: 3000
        ROOT_URL: https://git.<secret:private-domain>/
        LFS_START_SERVER: true
      database:
        DB_TYPE: postgres
        HOST: giteadb-cnpg-rw
        NAME: app
        SSL_MODE: require
      service:
        DISABLE_REGISTRATION: true
        ENABLE_CAPTCHA: true
        DEFAULT_KEEP_EMAIL_PRIVATE: true
        DEFAULT_ALLOW_CREATE_ORGANIZATION: false
      cors:
        ENABLED: true
        SCHEME: https
        ALLOW_DOMAIN: <secret:private-domain>
        ALLOW_SUBDOMAIN: true
        METHODS: "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS"
        MAX_AGE: 10m
        ALLOW_CREDENTIALS: false
      session:
        PROVIDER: redis-cluster
        PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      cache:
        ENABLED: true
        ADAPTER: redis-cluster
        HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
      queue:
        TYPE: redis
        CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
  ingress:
    enabled: true
    annotations: { kubernetes.io/ingress.class: traefik }
    hosts:
      - host: git.<secret:private-domain>
        paths:
          - path: /
            pathType: Prefix

I had to manually change app.ini file.

> Do you have them below `gitea.config`? Yes, this looks like this ``` image: repository: gitea/gitea tag: 1.20.0 pullPolicy: IfNotPresent rootless: true # only possible when running 1.14 or later podSecurityContext: fsGroup: 1000 gitea: config: APP_NAME: "Gitea: Git with a cup of tea" RUN_MODE: "prod" RUN_USER: "git" server: APP_DATA_PATH: "/data" DOMAIN: git.<secret:private-domain> SSH_DOMAIN: git.<secret:private-domain> HTTP_PORT: 3000 ROOT_URL: https://git.<secret:private-domain>/ LFS_START_SERVER: true database: DB_TYPE: postgres HOST: giteadb-cnpg-rw NAME: app SSL_MODE: require service: DISABLE_REGISTRATION: true ENABLE_CAPTCHA: true DEFAULT_KEEP_EMAIL_PRIVATE: true DEFAULT_ALLOW_CREATE_ORGANIZATION: false cors: ENABLED: true SCHEME: https ALLOW_DOMAIN: <secret:private-domain> ALLOW_SUBDOMAIN: true METHODS: "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS" MAX_AGE: 10m ALLOW_CREDENTIALS: false session: PROVIDER: redis-cluster PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& cache: ENABLED: true ADAPTER: redis-cluster HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& queue: TYPE: redis CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.gitea.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& ingress: enabled: true annotations: { kubernetes.io/ingress.class: traefik } hosts: - host: git.<secret:private-domain> paths: - path: / pathType: Prefix ``` I had to manually change `app.ini` file.

pat-s commented 2023-07-19 08:39:50 +00:00

Member

Copy Link

Hmm strange. I don't have issues changing values which then populate to app.ini - and I am using the current release version.

If you set values explicitly, it should definitely work and this is different to #356. Need to look into it...

Hmm strange. I don't have issues changing values which then populate to `app.ini` - and I am using the current release version. If you set values explicitly, it *should* definitely work and this is different to #356. Need to look into it...

smolinari commented 2023-07-19 11:16:51 +00:00

Copy Link

@smolinari Redis support has been there before this release, for both cluster and non-cluster versions.

I am not familiar with Redis auth but the chart shouldn't limit you here. Maybe it works via additional options in the connection string as documented here?

I think your request might be better suited in upstream Gitea than here as the helm chart does not anything special to redis auth, i.e. the change in v9.0.0 just switched the default to redis-cluster but all configuration options WRT to redis are the same as before.

Happy to document it but I think the information should then also go to the official Gitea docs and not the helm docs. Let's move this discussion to a new issue as this issue is actually about something else.

Thanks for the reply. I've made a suggestion issue on the Github Gitea repo. I hope that is the right place: 😁

Scott

> @smolinari Redis support has been there before this release, for both cluster and non-cluster versions. > > I am not familiar with Redis auth but the chart shouldn't limit you here. Maybe it works via additional options in the connection string as documented [here](https://docs.gitea.com/next/administration/config-cheat-sheet?_highlight=redis#queue-queue-and-queue)? > > I think your request might be better suited in upstream Gitea than here as the helm chart does not anything special to redis auth, i.e. the change in v9.0.0 just switched the default to `redis-cluster` but all configuration options WRT to redis are the same as before. > > Happy to document it but I think the information should then also go to the official Gitea docs and not the helm docs. Let's move this discussion to a new issue as this issue is actually about something else. Thanks for the reply. I've made a suggestion issue on the Github Gitea repo. I hope that is the right place: 😁 Scott

👍 1

pat-s commented 2023-07-19 20:55:53 +00:00

Member

Copy Link

@mmalyska @viceice

Caused by an upstream bug in 1.20.0: https://github.com/go-gitea/gitea/issues/25924

You have the following options:

• Use 1.20-nightly
• Wait for 1.20.1`
• Remove INSTALL_LOCK = true manually from app.ini and set GITEA__security__INSTALL_LOCK as an env var in the pod via additionalConfigFromEnvs

@mmalyska @viceice Caused by an upstream bug in 1.20.0: https://github.com/go-gitea/gitea/issues/25924 You have the following options: - Use `1.20-nightly` - Wait for 1.20.1` - Remove `INSTALL_LOCK = true` manually from `app.ini` and set `GITEA__security__INSTALL_LOCK` as an env var in the pod via `additionalConfigFromEnvs`

pat-s added the

upstream

gitea

label 2023-07-19 20:57:47 +00:00

pat-s commented 2023-07-22 12:11:55 +00:00

Member

Copy Link

@mmalyska @viceice This should be fixed now in v9.0.4.

@mmalyska @viceice This should be fixed now in v9.0.4.

👍 1

pat-s commented 2023-07-24 20:39:03 +00:00

Member

Copy Link

Closing since #468 (comment) should solve this (which is also linked in the upgrading notes).

Closing since https://gitea.com/gitea/helm-chart/issues/468#issuecomment-744807 should solve this (which is also linked in the upgrading notes).

pat-s closed this issue 2023-07-24 20:39:03 +00:00

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.

No Branch/Tag Specified

Branches Tags

main

app-ini-recreation

fix-env-to-ini

clean-app-ini

gitea-ha

v10.2.0

v10.1.4

v10.1.3

v10.1.2

v10.1.1

v10.1.0

v10.0.2

v10.0.1

v10.0.0

v9.6.1

v9.6.0

v9.5.1

v9.5.0

v9.4.0

v9.3.0

v9.2.1

v9.2.0

v9.1.0

v9.0.4

v9.0.3

v9.0.2

v9.0.1

v9.0.0

v8.3.0

v8.2.0

v8.1.0

v8.0.3

v8.0.2

v8.0.1

v8.0.0

v7.0.4

v7.0.3

v7.0.2

v7.0.1

v7.0.0

v6.0.5

v6.0.4

v6.0.3

v6.0.2

v6.0.1

v6.0.0

v5.0.9

v5.0.8

v5.0.7

v5.0.6

v5.0.5

v5.0.4

v5.0.3

v5.0.2

v5.0.1

v5.0.0

v4.1.1

v4.1.0

v4.0.3

v4.0.2

v4.0.1

v4.0.0

v3.1.4

v3.1.3

v3.1.2

v3.1.1

v3.1.0

v3.0.0

v2.2.5

v2.2.4

v2.2.3

v2.2.2

v2.2.1

v2.2.0

v2.1.11

v2.1.10

v2.1.9

v2.1.8

v2.1.7

v2.1.6

v2.1.5

v2.1.4

v2.1.3

v2.1.2

v2.1.1

v2.1.0

v2.0.7

v2.0.6

v2.0.5

v2.0.4

v2.0.3

v2.0.2

v2.0.0

v1.5.5

v1.5.4

v1.5.3

v1.5.2

v1.5.1

v1.5.0

v1.4.9

v1.4.8

v1.4.7

v1.4.6

v1.4.5

v1.4.4

v1.4.3

v1.4.2

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

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

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

5 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#468

No description provided.