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

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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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?
smolinari commented 2023-07-19 07:02:19 +00:00 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 (Migrated from gitea.com)
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 commented 2023-07-22 12:11:55 +00:00 (Migrated from gitea.com)
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 (Migrated from gitea.com)
Copy Link

Closing since https://gitea.com/gitea/helm-chart/issues/468#issuecomment-744807 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).
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/bug
priority/critical
upstream/gitea
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#468
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?