I'm trying to deploy this chart into our Openshift at work using ArgoCD and seeing the pods crash loop back off with an error like this:

error: MongoNetworkError: getaddrinfo ENOTFOUND food-for-thought-wekan-stage-app-mongodb-2.food-for-thought-wekan-stage-app-mongodb
                        at connectionFailureError (/build/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:387:20)
                        at Socket.<anonymous> (/build/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/cmap/connect.js:310:22)
                        at Object.onceWrapper (events.js:520:26)
                        at Socket.emit (events.js:400:28)
                        at emitErrorNT (internal/streams/destroy.js:106:8)
                        at emitErrorCloseNT (internal/streams/destroy.js:74:3)
                        at processTicksAndRejections (internal/process/task_queues.js:82:21) {
                      cause: Error: getaddrinfo ENOTFOUND food-for-thought-wekan-stage-app-mongodb-2.food-for-thought-wekan-stage-app-mongodb
                          at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:71:26) {
                        errno: -3008,
                        code: 'ENOTFOUND',
                        syscall: 'getaddrinfo',
                        hostname: 'food-for-thought-wekan-stage-app-mongodb-2.food-for-thought-wekan-stage-app-mongodb'
                      },
                      [Symbol(errorLabels)]: Set(1) { 'ResetPool' }

The mongodb.url section in _helpers.tpl looks like it only looks at mongodb.replicaCount, which according to the mongodb chart itself is ignored when the mongodb.architecture is set to "standalone". So if setting the Mongo architecture to standalone, the Deployment ends up being created with a MONGO_URL environment variable that doesn't actually point to the MongoDB. I may be able to work around this by using the replicaset architecture but it feels like it may be overkill for my purposes.

Add port value, or use service.port (8080 by default)

Use this value in deployment.yaml, to ports and livenessProbe/readinessProbe sections

values.yml suggests that you can use an existing PVC by setting mongodb.persistence.existingClaim, but that claim will not actually be used unless you also set mongodb.architecture: standalone and mongodb.useStatefulSet: false.

Hello, I found an issue with the secretEnv today after upgrading to latest version. @xet7

5dfb6b7#diff-297fc75fd4942cbe9e1736dd8b8f814dffe2f59687bebfe92ac1dcf8dc5a4b92L8

The change itself seems fine, but I guess the indentation was lost in the process.

before it was:

data:
  {{- range $key := .Values.secretEnv }}

now it is;

data:
{{ $key.name }}: {{ $key.value | b64enc }}

if I place values now into secretEnv, they will be added to the secret like:

data:
OAUTH2_SECRET: 

with missing indentation and therefore breaking the secret

Helm upgrade failed: error validating "": error validating data: ValidationError(Secret): unknown field "OAUTH2_SECRET" in io.k8s.api.core.v1.Secret

I think i have to open a PR to fix it

Since 0997288 it seems like chart version 1.1.1 (added in 6184a1b) is not available anymore. It also seems like that commit changed the app version metadata without changing anything about the actual chart(s) provided (except removind 1.1.1). However, it seems like the chart that is in the wekan/wekan repository is updated.

The Wekan chart situation is a bit confusing too. There is a helm chart in this repository. https://wekan.github.io/charts/ points to this repository too. But it seems like the chart that is used (and possibly even the chart that is served in this repo's gh-pages branch) is the one from wekan/wekan.

If my hunches are correct, this is what I think would be a solution for the confusion as well as the currently missing chart(s):

1. Remove the wekan folder from this repository
2. Follow the "publish chart" readme @varac wrote for future chart versions (https://github.com/wekan/charts/blob/gh-pages/README.publish-chart.md) -- including the chart version upgrade in wekan/wekan and the helm package and helm repo index commands in this repository (note that the README.publis-chart.md doesn't mention the git add and git commit commands necessary to actually make the charts reachable.

I recently tried to deploy the latest Chart from "main" and I noticed that the deployment failed due to mongo-db issues.
Currently the Chart.yaml contains

dependencies:
  - condition: mongodb.enabled
    name: mongodb
    repository: https://charts.bitnami.com/bitnami
    version: 10.0.x

Checking in bitnami ( https://artifacthub.io/packages/helm/bitnami/mongodb ), I can see the oldest available version is 12.XX

So the Chart should be updated to v. 12 or v. 13 accordingly.

Well, I figured out how to publich newest Helm Chart to https://artifacthub.io/packages/helm/wekan/wekan , include required mongodb, etc. and install it with microk8s and helm with:

helm install my-wekan wekan/wekan

So it seems to install, but how can I see login page etc? I'm just trying to figure out this helm stuff.

Add readinessProbe to deployment.yaml:

          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 20

Moved to here from wekan/wekan#5026

From @johanneskastl

Hi all,

I just installed wekan using the helm chart. And I am not sure if the UI displays properly, e.g. the dropdwon-menu on the right (for the current user) has strange names for the entries).

In addition, my Firefox umatrix plugin states that some resources are being loaded from wekan.local instead of the FQDN that I set in my values.yaml.

endpoint: wekan.example.org
ingress:
  enabled: false
  hosts: [ "wekan.example.org"]

(The ingress is disabled, as I am providing my own ingressroutes via Traefik, but that should not matter here)

Should wekan.local be included in the endpoint, as it seems to be used internally? I tested it, it did not improve the UI glitches but I noticed no additional breakage. So I would omit it (as it will not resolve anyway)

Thanks in advance,
Johannes

@Nightreaver @szechp @jadams @salleman33 @jehutyy @luclu @varac

Do you know about this?

Or is this related to environment variables ROOT_URL and PORT https://github.com/wekan/wekan/wiki/Settings wekan/wekan#4932 ?

Issue

Current templates/secret.yaml runs Secret api on every item in secretEnv.
If you have several secretEnv, for example:

secretEnv:
  - name: "MAIL_SERVICE_USER"
    value: "123"    
  - name: "MAIL_SERVICE_PASSWORD"
    value: "321"

It will run run same resource two times and add only MAIL_SERVICE_PASSWORD (last) secret.

Fix

Move range loop and add "-" to avoid newlines:

{{ if .Values.secretEnv }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ template "wekan.fullname" $ }}-secret
type: Opaque
data:
{{- range $key := .Values.secretEnv -}}
{{ if $key.value }}
{{ $key.name | indent 2 }}: {{ $key.value | b64enc }}
{{- end }}
{{- end }}
{{ end }}

Original code:

{{ if .Values.secretEnv }}
{{- range $key := .Values.secretEnv }}
{{ if $key.value }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ template "wekan.fullname" $ }}-secret
type: Opaque
data:
{{ $key.name | indent 2 }}: {{ $key.value | b64enc }}
{{ end }}
{{- end}}
{{ end }}

When configuring the Helm values to run wekan under a subpath, the readiness and liveliness probes are still configured to call the root path /. This returns a 404 Not Found and results in the probe(s) failing, which ultimately results in Kubernetes killing the pod.

Relevent config:

# values.yml
endpoint: my.website.com
root_url: https://my.website.com/wekan
ingress:
  path: /wekan
  hosts: [ my.website.com ]

When I manually updated the deployment to set the readiness/liveliness probe URL to /wekan, then everything worked.

Setting mongodb.architecture to standalone provides an MongoNetworkError: connect ECONNREFUSED
Reverting to replicaset works fine

I'm pretty new. So ask if more information are needed.

Hello,

I just figured out that in docker-compose.yaml you are setting a path to store attachments and avatar icons. ( https://github.com/wekan/wekan/blob/master/docker-compose.yml#L149 )
But it seems there no volume/pvc defined in this helm chart, is this an oversight or am I missing something?