Provide gitea-ha support -> multiple replicas #206

New Issue

Closed

opened 2021-07-09 14:49:23 +00:00 by luhahn · 9 comments

luhahn commented 2021-07-09 14:49:23 +00:00 (Migrated from gitea.com)

Copy Link

As of now it is possible to run gitea with multiple replicas with the helm chart,
however a lot of configuration is needed.

This could be included in the helm chart.

As of now it is possible to run gitea with multiple replicas with the helm chart, however a lot of configuration is needed. This could be included in the helm chart.

👍 1

pat-s commented 2021-09-24 13:28:51 +00:00 (Migrated from gitea.com)

Copy Link

Is this already possible? I've set replicaCount: 2 and it seems to work as expected for now - did not do extensive testing yet though.

Is this already possible? I've set `replicaCount: 2` and it seems to work as expected for now - did not do extensive testing yet though.

viceice commented 2021-11-23 14:46:12 +00:00 (Migrated from gitea.com)

Copy Link

Yes, it's working fine, but needs lots of configuration. ?
My Gitea values.yaml is about 300 LOC for this. ?

Yes, it's working fine, but needs lots of configuration. ? My Gitea `values.yaml` is about 300 LOC for this. ?

Sindvero commented 2021-12-06 16:13:12 +00:00 (Migrated from gitea.com)

Copy Link

Can you provide example on how to configure gitea for HA, like did you configure redis in the config?

Thank you

Can you provide example on how to configure gitea for HA, like did you configure redis in the config? Thank you

viceice commented 2021-12-06 17:24:42 +00:00 (Migrated from gitea.com)

Copy Link

Removed some unrelated settings:

replicaCount: 2

image:
  repository: gitea/gitea
  tag: 1.15.7
  rootless: true

gitea:
  database:
    builtIn:
      postgresql:
        enabled: false
  cache:
    builtIn:
      enabled: false

  config:
    database:
      DB_TYPE: postgres
      HOST: postgresql.db:5432
      NAME: gitea
      USER: gitea
      LOG_SQL: false
      MAX_IDLE_CONNS: 10
      CONN_MAX_LIFE_TIME: 5m
    server:
      DISABLE_SSH: true
      LANDING_PAGE: login


    cache:
      ADAPTER: redis
      ITEM_TTL: 72h

    queue:
      TYPE: redis

    session:
      PROVIDER: redis
      COOKIE_SECURE: true

    indexer:
      ISSUE_INDEXER_TYPE: elasticsearch
      ISSUE_INDEXER_CONN_STR: http://${search-server}:9200
      REPO_INDEXER_ENABLED: true
      REPO_INDEXER_TYPE: elasticsearch
      REPO_INDEXER_CONN_STR: http://${search-server}:9200


    attachment:
      MAX_SIZE: 50
      STORAGE_TYPE: minio
    lfs:
      STORAGE_TYPE: minio
    picture:
      AVATAR_STORAGE_TYPE: minio
      REPOSITORY_AVATAR_STORAGE_TYPE: minio

    storage:
      MINIO_ENDPOINT: s3.xxxx.de
      MINIO_LOCATION: md-hq-1
      MINIO_ACCESS_KEY_ID: xxxxx
      MINIO_BUCKET: gitea
      MINIO_USE_SSL: true

    storage.repo-archive:
      STORAGE_TYPE: minio

initPreScript: |
  [ -d /data/gitea ] && chmod 700 /data/gitea

Other params are set via terraform

resource "helm_release" "gitea" {
  depends_on = [
    helm_release.keydb,
    helm_release.opensearch,
  ]

  name      = "gitea"
  namespace = local.namespace

  repository = "https://dl.gitea.io/charts"
  chart      = "gitea"
  version    = "4.1.1"

  max_history = 10

  values = [
    templatefile("${path.module}/gitea/values.yaml", {
      search-server     = "${helm_release.opensearch.name}-master"
      cm-files          = kubernetes_config_map.gitea_files.metadata.0.name
      cm-files-checksum = base64sha256(jsonencode(kubernetes_config_map.gitea_files.data))
    })
  ]


  set_sensitive {
    name  = "gitea.config.database.PASSWD"
    value = var.passwords.postgresql.gitea
  }

  set_sensitive {
    name  = "gitea.config.security.SECRET_KEY"
    value = local.gitea_sk
  }

  set_sensitive {
    name  = "gitea.config.storage.MINIO_SECRET_ACCESS_KEY"
    value = var.passwords.minio.gitea
  }

  set_sensitive {
    name  = "gitea.config.oauth2.JWT_SECRET"
    value = var.passwords.gitea.jwt_token
  }

  set_sensitive {
    name  = "gitea.config.cache.HOST"
    value = local.redis_cs
  }

  set_sensitive {
    name  = "gitea.config.queue.CONN_STR"
    value = local.redis_cs
  }

  set_sensitive {
    name  = "gitea.config.session.PROVIDER_CONFIG"
    value = local.redis_cs
  }

  set {
    name  = "gitea.admin.existingSecret"
    value = kubernetes_secret.gitea_admin.metadata.0.name
  }

  set {
    name  = "gitea.ldap.existingSecret"
    value = kubernetes_secret.gitea_ldap.metadata.0.name
  }


  set {
    name  = "persistence.existingClaim"
    value = kubernetes_persistent_volume_claim.gitea_data.metadata.0.name
  }
}

locals {
  redis_cs        = "redis://${local.redis_password}@${helm_release.keydb.name}:6379/0?pool_size=100&idle_timeout=180s"
}

I'm using keydb as redis and opensearch as elasticsearch replacement

• https://artifacthub.io/packages/helm/enapter/keydb
• https://artifacthub.io/packages/helm/opensearch-project-helm-charts/opensearch

Removed some unrelated settings: ```yml replicaCount: 2 image: repository: gitea/gitea tag: 1.15.7 rootless: true gitea: database: builtIn: postgresql: enabled: false cache: builtIn: enabled: false config: database: DB_TYPE: postgres HOST: postgresql.db:5432 NAME: gitea USER: gitea LOG_SQL: false MAX_IDLE_CONNS: 10 CONN_MAX_LIFE_TIME: 5m server: DISABLE_SSH: true LANDING_PAGE: login cache: ADAPTER: redis ITEM_TTL: 72h queue: TYPE: redis session: PROVIDER: redis COOKIE_SECURE: true indexer: ISSUE_INDEXER_TYPE: elasticsearch ISSUE_INDEXER_CONN_STR: http://${search-server}:9200 REPO_INDEXER_ENABLED: true REPO_INDEXER_TYPE: elasticsearch REPO_INDEXER_CONN_STR: http://${search-server}:9200 attachment: MAX_SIZE: 50 STORAGE_TYPE: minio lfs: STORAGE_TYPE: minio picture: AVATAR_STORAGE_TYPE: minio REPOSITORY_AVATAR_STORAGE_TYPE: minio storage: MINIO_ENDPOINT: s3.xxxx.de MINIO_LOCATION: md-hq-1 MINIO_ACCESS_KEY_ID: xxxxx MINIO_BUCKET: gitea MINIO_USE_SSL: true storage.repo-archive: STORAGE_TYPE: minio initPreScript: | [ -d /data/gitea ] && chmod 700 /data/gitea ``` Other params are set via terraform ```hcl resource "helm_release" "gitea" { depends_on = [ helm_release.keydb, helm_release.opensearch, ] name = "gitea" namespace = local.namespace repository = "https://dl.gitea.io/charts" chart = "gitea" version = "4.1.1" max_history = 10 values = [ templatefile("${path.module}/gitea/values.yaml", { search-server = "${helm_release.opensearch.name}-master" cm-files = kubernetes_config_map.gitea_files.metadata.0.name cm-files-checksum = base64sha256(jsonencode(kubernetes_config_map.gitea_files.data)) }) ] set_sensitive { name = "gitea.config.database.PASSWD" value = var.passwords.postgresql.gitea } set_sensitive { name = "gitea.config.security.SECRET_KEY" value = local.gitea_sk } set_sensitive { name = "gitea.config.storage.MINIO_SECRET_ACCESS_KEY" value = var.passwords.minio.gitea } set_sensitive { name = "gitea.config.oauth2.JWT_SECRET" value = var.passwords.gitea.jwt_token } set_sensitive { name = "gitea.config.cache.HOST" value = local.redis_cs } set_sensitive { name = "gitea.config.queue.CONN_STR" value = local.redis_cs } set_sensitive { name = "gitea.config.session.PROVIDER_CONFIG" value = local.redis_cs } set { name = "gitea.admin.existingSecret" value = kubernetes_secret.gitea_admin.metadata.0.name } set { name = "gitea.ldap.existingSecret" value = kubernetes_secret.gitea_ldap.metadata.0.name } set { name = "persistence.existingClaim" value = kubernetes_persistent_volume_claim.gitea_data.metadata.0.name } } locals { redis_cs = "redis://${local.redis_password}@${helm_release.keydb.name}:6379/0?pool_size=100&idle_timeout=180s" } ``` I'm using `keydb` as `redis` and `opensearch` as `elasticsearch` replacement - https://artifacthub.io/packages/helm/enapter/keydb - https://artifacthub.io/packages/helm/opensearch-project-helm-charts/opensearch

❤️ 3

lunny commented 2021-12-07 03:52:16 +00:00 (Migrated from gitea.com)

Copy Link

Removed some unrelated settings:

replicaCount: 2

image:
  repository: gitea/gitea
  tag: 1.15.7
  rootless: true

gitea:
  database:
    builtIn:
      postgresql:
        enabled: false
  cache:
    builtIn:
      enabled: false

  config:
    database:
      DB_TYPE: postgres
      HOST: postgresql.db:5432
      NAME: gitea
      USER: gitea
      LOG_SQL: false
      MAX_IDLE_CONNS: 10
      CONN_MAX_LIFE_TIME: 5m
    server:
      DISABLE_SSH: true
      LANDING_PAGE: login


    cache:
      ADAPTER: redis
      ITEM_TTL: 72h

    queue:
      TYPE: redis

    session:
      PROVIDER: redis
      COOKIE_SECURE: true

    indexer:
      ISSUE_INDEXER_TYPE: elasticsearch
      ISSUE_INDEXER_CONN_STR: http://${search-server}:9200
      REPO_INDEXER_ENABLED: true
      REPO_INDEXER_TYPE: elasticsearch
      REPO_INDEXER_CONN_STR: http://${search-server}:9200


    attachment:
      MAX_SIZE: 50
      STORAGE_TYPE: minio
    lfs:
      STORAGE_TYPE: minio
    picture:
      AVATAR_STORAGE_TYPE: minio
      REPOSITORY_AVATAR_STORAGE_TYPE: minio

    storage:
      MINIO_ENDPOINT: s3.xxxx.de
      MINIO_LOCATION: md-hq-1
      MINIO_ACCESS_KEY_ID: xxxxx
      MINIO_BUCKET: gitea
      MINIO_USE_SSL: true

    storage.repo-archive:
      STORAGE_TYPE: minio

initPreScript: |
  [ -d /data/gitea ] && chmod 700 /data/gitea

Other params are set via terraform

resource "helm_release" "gitea" {
  depends_on = [
    helm_release.keydb,
    helm_release.opensearch,
  ]

  name      = "gitea"
  namespace = local.namespace

  repository = "https://dl.gitea.io/charts"
  chart      = "gitea"
  version    = "4.1.1"

  max_history = 10

  values = [
    templatefile("${path.module}/gitea/values.yaml", {
      search-server     = "${helm_release.opensearch.name}-master"
      cm-files          = kubernetes_config_map.gitea_files.metadata.0.name
      cm-files-checksum = base64sha256(jsonencode(kubernetes_config_map.gitea_files.data))
    })
  ]


  set_sensitive {
    name  = "gitea.config.database.PASSWD"
    value = var.passwords.postgresql.gitea
  }

  set_sensitive {
    name  = "gitea.config.security.SECRET_KEY"
    value = local.gitea_sk
  }

  set_sensitive {
    name  = "gitea.config.storage.MINIO_SECRET_ACCESS_KEY"
    value = var.passwords.minio.gitea
  }

  set_sensitive {
    name  = "gitea.config.oauth2.JWT_SECRET"
    value = var.passwords.gitea.jwt_token
  }

  set_sensitive {
    name  = "gitea.config.cache.HOST"
    value = local.redis_cs
  }

  set_sensitive {
    name  = "gitea.config.queue.CONN_STR"
    value = local.redis_cs
  }

  set_sensitive {
    name  = "gitea.config.session.PROVIDER_CONFIG"
    value = local.redis_cs
  }

  set {
    name  = "gitea.admin.existingSecret"
    value = kubernetes_secret.gitea_admin.metadata.0.name
  }

  set {
    name  = "gitea.ldap.existingSecret"
    value = kubernetes_secret.gitea_ldap.metadata.0.name
  }


  set {
    name  = "persistence.existingClaim"
    value = kubernetes_persistent_volume_claim.gitea_data.metadata.0.name
  }
}

locals {
  redis_cs        = "redis://${local.redis_password}@${helm_release.keydb.name}:6379/0?pool_size=100&idle_timeout=180s"
}

I'm using keydb as redis and opensearch as elasticsearch replacement

• https://artifacthub.io/packages/helm/enapter/keydb
• https://artifacthub.io/packages/helm/opensearch-project-helm-charts/opensearch

The example is perfect. Only one thing which is Gitea's problem is every instance will run the cron jobs. A simple method is to add a command line flag to disable or enable all cron jobs which is not implemented by v1.15.7. A better case is Gitea cluster, all Gitea replications could know each other and will elect one to run cron jobs.

> Removed some unrelated settings: > ```yml > replicaCount: 2 > > image: > repository: gitea/gitea > tag: 1.15.7 > rootless: true > > gitea: > database: > builtIn: > postgresql: > enabled: false > cache: > builtIn: > enabled: false > > config: > database: > DB_TYPE: postgres > HOST: postgresql.db:5432 > NAME: gitea > USER: gitea > LOG_SQL: false > MAX_IDLE_CONNS: 10 > CONN_MAX_LIFE_TIME: 5m > server: > DISABLE_SSH: true > LANDING_PAGE: login > > > cache: > ADAPTER: redis > ITEM_TTL: 72h > > queue: > TYPE: redis > > session: > PROVIDER: redis > COOKIE_SECURE: true > > indexer: > ISSUE_INDEXER_TYPE: elasticsearch > ISSUE_INDEXER_CONN_STR: http://${search-server}:9200 > REPO_INDEXER_ENABLED: true > REPO_INDEXER_TYPE: elasticsearch > REPO_INDEXER_CONN_STR: http://${search-server}:9200 > > > attachment: > MAX_SIZE: 50 > STORAGE_TYPE: minio > lfs: > STORAGE_TYPE: minio > picture: > AVATAR_STORAGE_TYPE: minio > REPOSITORY_AVATAR_STORAGE_TYPE: minio > > storage: > MINIO_ENDPOINT: s3.xxxx.de > MINIO_LOCATION: md-hq-1 > MINIO_ACCESS_KEY_ID: xxxxx > MINIO_BUCKET: gitea > MINIO_USE_SSL: true > > storage.repo-archive: > STORAGE_TYPE: minio > > initPreScript: | > [ -d /data/gitea ] && chmod 700 /data/gitea > > ``` > > Other params are set via terraform > > ```hcl > resource "helm_release" "gitea" { > depends_on = [ > helm_release.keydb, > helm_release.opensearch, > ] > > name = "gitea" > namespace = local.namespace > > repository = "https://dl.gitea.io/charts" > chart = "gitea" > version = "4.1.1" > > max_history = 10 > > values = [ > templatefile("${path.module}/gitea/values.yaml", { > search-server = "${helm_release.opensearch.name}-master" > cm-files = kubernetes_config_map.gitea_files.metadata.0.name > cm-files-checksum = base64sha256(jsonencode(kubernetes_config_map.gitea_files.data)) > }) > ] > > > set_sensitive { > name = "gitea.config.database.PASSWD" > value = var.passwords.postgresql.gitea > } > > set_sensitive { > name = "gitea.config.security.SECRET_KEY" > value = local.gitea_sk > } > > set_sensitive { > name = "gitea.config.storage.MINIO_SECRET_ACCESS_KEY" > value = var.passwords.minio.gitea > } > > set_sensitive { > name = "gitea.config.oauth2.JWT_SECRET" > value = var.passwords.gitea.jwt_token > } > > set_sensitive { > name = "gitea.config.cache.HOST" > value = local.redis_cs > } > > set_sensitive { > name = "gitea.config.queue.CONN_STR" > value = local.redis_cs > } > > set_sensitive { > name = "gitea.config.session.PROVIDER_CONFIG" > value = local.redis_cs > } > > set { > name = "gitea.admin.existingSecret" > value = kubernetes_secret.gitea_admin.metadata.0.name > } > > set { > name = "gitea.ldap.existingSecret" > value = kubernetes_secret.gitea_ldap.metadata.0.name > } > > > set { > name = "persistence.existingClaim" > value = kubernetes_persistent_volume_claim.gitea_data.metadata.0.name > } > } > > locals { > redis_cs = "redis://${local.redis_password}@${helm_release.keydb.name}:6379/0?pool_size=100&idle_timeout=180s" > } > > ``` > > I'm using `keydb` as `redis` and `opensearch` as `elasticsearch` replacement > - https://artifacthub.io/packages/helm/enapter/keydb > - https://artifacthub.io/packages/helm/opensearch-project-helm-charts/opensearch The example is perfect. Only one thing which is Gitea's problem is every instance will run the cron jobs. A simple method is to add a command line flag to disable or enable all cron jobs which is not implemented by v1.15.7. A better case is Gitea cluster, all Gitea replications could know each other and will elect one to run cron jobs.

justusbunsi commented 2021-12-17 17:07:50 +00:00 (Migrated from gitea.com)

Copy Link

A better case is Gitea cluster, all Gitea replications could know each other and will elect one to run cron jobs.

That would be good. Do you think it's a thing to implement in the Chart or in Gitea itself?

> A better case is Gitea cluster, all Gitea replications could know each other and will elect one to run cron jobs. That would be good. Do you think it's a thing to implement in the Chart or in Gitea itself?

👍 1

Sindvero commented 2021-12-20 00:17:20 +00:00 (Migrated from gitea.com)

Copy Link

That would be awesome! I just found this issue on their github: https://github.com/go-gitea/gitea/issues/13791

So I guess they would eventually make it possible. I'm not sure we can implement it in the Chart before they did it in Gitea itself

That would be awesome! I just found this issue on their github: https://github.com/go-gitea/gitea/issues/13791 So I guess they would eventually make it possible. I'm not sure we can implement it in the Chart before they did it in Gitea itself

pat-s commented 2022-08-13 09:25:52 +00:00 (Migrated from gitea.com)

Copy Link

I've spent some time revisiting the current state, especially #205 and #206.
I'll try to replicate the setup posted from @viceice in the next days/weeks and see how far I can go.

Of course there is still #205 which aims to provide a built-in solution for HA. While this would of course be nice (!), I wonder if we should rather focus on documenting HA requirements and configuration changes given all the considerations one has to make when going HA here (indexer, memcache, attachment storage, etc.).
If this is done and people have a guide how to go HA with their setup, one could focus on a "simple" default config within the chart as in #206 for a "best effort" config solution that does not require multiple additional chart deployments?

I think it could be worth adding a dedicated markdown doc (e.g. ha-setup.md) into here (next to the README or within docs/ or config/) and explain what is needed and what are possible options to achieve this.

For example, outlining that elasticsearch (or similar) is required as a code indexer which itself requires quite some resources on a cluster (4-8 GB and multiple nodes) AFAICS. Such information might already put the topic off the table for some as their cluster is not that large.

I really see the need to consolidate information from #205 and #206 as otherwise it will get lost over time and it is really hard for users to grasp the current state. I am aware of the Gitea-internal issue of cron jobs running multiple times as described in #205, but I guess for most users this might be acceptable in a trade-off for a HA setup.

AFAICS, and mainly putting things together from @lunny comment in https://gitea.com/gitea/helm-chart/pulls/205#issuecomment-593662:

Additional/External requirements for Gitea HA

(Happy to edit this list or put it into a dedicated markdown doc in the repo)

• A HA-ready code indexer (elasticsearch or similar, 4-8 GB in memory)
• A HA-ready external object storage (minio)
• A HA-ready memcache (e.g. redis or similar)
• A RWX file-system (e.g. NFS or EFS (AWS), or similar)

I've spent some time revisiting the current state, especially #205 and #206. I'll try to replicate the setup posted from @viceice in the next days/weeks and see how far I can go. Of course there is still #205 which aims to provide a built-in solution for HA. While this would of course be nice (!), I wonder if we should rather focus on documenting HA requirements and configuration changes given all the considerations one has to make when going HA here (indexer, memcache, attachment storage, etc.). If this is done and people have a guide how to go HA with their setup, one could focus on a "simple" default config within the chart as in #206 for a "best effort" config solution that does not require multiple additional chart deployments? I think it could be worth adding a dedicated markdown doc (e.g. `ha-setup.md`) into here (next to the README or within `docs/` or `config/`) and explain what is needed and what are possible options to achieve this. For example, outlining that `elasticsearch` (or similar) is required as a code indexer which itself requires quite some resources on a cluster (4-8 GB and multiple nodes) AFAICS. Such information might already put the topic off the table for some as their cluster is not that large. I really see the need to consolidate information from #205 and #206 as otherwise it will get lost over time and it is really hard for users to grasp the current state. I am aware of the Gitea-internal issue of cron jobs running multiple times as described in #205, but I guess for most users this might be acceptable in a trade-off for a HA setup. AFAICS, and mainly putting things together from @lunny comment in https://gitea.com/gitea/helm-chart/pulls/205#issuecomment-593662: ### Additional/External requirements for Gitea HA (Happy to edit this list or put it into a dedicated markdown doc in the repo) - A HA-ready code indexer (`elasticsearch` or similar, 4-8 GB in memory) - A HA-ready external object storage (`minio`) - A HA-ready memcache (e.g. `redis` or similar) - A RWX file-system (e.g. NFS or EFS (AWS), or similar)

👍 2

pat-s commented 2023-07-17 20:00:06 +00:00 (Migrated from gitea.com)

Copy Link

Done in #437.

Done in #437.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

renovate/postgresql-ha-15.x

renovate/postgresql-16.x

renovate/redis-20.x

renovate/redis-cluster-11.x

fix-674

app-ini-recreation

fix-env-to-ini

clean-app-ini

gitea-ha

v10.6.0

v10.5.0

v10.4.1

v10.4.0

v10.3.0

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

kind/feature

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

lunny

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#206

No description provided.