martialblog / helm-charts Goto Github PK

Not an issue, just confusing.

When someone changes the Image tag, for example when running '3-apache'

image:
  tag: '3-apache'

The label will still be

labels:
  app.kubernetes.io/version: 5-apache

Maybe we should use coalesce in _helpers instead:

{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}

should:

app.kubernetes.io/version: {{ coalesce .Values.image.tag .Chart.AppVersion | quote }}

https://helm.sh/docs/chart_template_guide/function_list/#coalesce

For example if you set

ingress:
  enabled: true
  hosts:
    - host: limesurvey.local
      paths:
        - path: /
          pathType: Prefix

then the baseUrl und publicURL need to be limesurvey.local. Maybe we can provide some logic to do that in the template, so that it works out-of-the-box

- name: BASE_URL
  value: {{ .Values.limesurvey.baseUrl }}
- name: PUBLIC_URL
  value: {{ .Values.limesurvey.publicUrl }}

We need a Release with GH Actions:

https://github.com/helm/chart-releaser-action

We should set up automation that will automatically create a new PR in this repo when there is a version available in martialblog/docker-limesurvey.

There is already a level of autogeneration of secrets, but there are still db passwords hardcoded in the configurations.
It seems to be easier to describe how to extract those from the cluster like in the gitlab manual and have all of those autogenerated

When a user gets to the end of a survey they receive the following error message.

Wrong decryption key! Decryption key has changed since this data were last saved, so data can't be decrypted. Please consult our manual at https://manual.limesurvey.org/Data_encryption#Errors.

Re-entering the email password in global settings resolves the issue until the pod is replaced.

Just a collection of links that are useful references:

• Grafana Helm Chart: https://github.com/grafana/helm-charts/tree/main/charts/grafana
• Bitnami MariaDB: https://github.com/bitnami/charts/tree/master/bitnami/mariadb
• Bitnami Wordpress: https://github.com/bitnami/charts/tree/master/bitnami/wordpress

I would like to use this feature, and I would like to know when you plan to bump the new chart version. Thank you.

We add the option to pass the LS configuration as a ConfigMap. The upstream Container is smart enough to accept an existing config.php

Has moved to https://github.com/helm-unittest/helm-unittest/

We should add ct-test to the GH action

As the value is needed, it seems it would be cleaner to use the default function instead of the if-else here

Whats your opinion?

Besides some Variables I don't think we need to change much for the LimeSurvey 3 LTS

These are not required:

  encrypt:
    keypair: ""
    publicKey: ""
    secretKey: ""
    nonce: ""
    secretBoxKey: ""

Anything else? 🤔

We currently have the config in the values.yaml but no dependency and deployment for an "intern" database deployment.

To help with the discoverability of this awesome chart(s), we should add it to Artifacthub.io, which is a central registry for Helm charts from various sources.

You can sign up with your Github account on Artifacthub.io and then hit "Add Repository" on this page:
https://artifacthub.io/control-panel/repositories

P.S. I didn't want to steal your chart :-)

Would be cool to have the option to rollout a Network Policy

Hi,

I noticed that the reference to the ejabberd chart has vanished from the index.yaml - I believe it used to be there.

https://martialblog.github.io/helm-charts/index.yaml

The last CI jobs also mentions the chart, so I'm not sure which puzzle piece is missing:

Looking up latest tag...
Discovering changed charts since 'ejabberd-0.1.0'...
WARNING: .github/Chart.yaml is missing, assuming that '.github' is not a Helm chart. Skipping.
Nothing to do. No chart changes detected.

https://github.com/martialblog/helm-charts/actions/runs/6081404816/job/16496989259

In our case, the default Timeout for liveness and readiness are 1s,

This sometimes set the Ready state to 0/1 as the pod was too slow to answer in a few cases.
Basically forcing the pod to restart.

Adjusting the Probe timeouts within the values chart may be helpful.

livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5
readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5

we just hardcoded the timout manually in the deployment.yaml currently, but adjusting it within the values yaml should help.

The pods readiness probes are generating large amount of logs.
Within one minute:

10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:17:55 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:17:55 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:05 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:05 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:15 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:15 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:25 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:25 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:35 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:35 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:45 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:45 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:55 +0000] "GET / HTTP/1.1" 200 46793 "-" "kube-probe/1.21"
10.42.0.17:80 10.42.0.1 - - [09/Jul/2021:20:18:55 +0000] "GET / HTTP/1.1" 200 46788 "-" "kube-probe/1.21"

We might want to reduce the interval.
Maybe we can tell Apache to shut up about these probes.

It would be useful to support setting the LDAP parameters without manually providing a file for it.
Not sure if this should be implemented here or in the Docker Repo or if it should be done in both

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update helm release mariadb to v18

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I think it would be neat to have more control over the initContainer (i.e. resources, secContext, etc).

Hey,

I'm not sure how much users of this chart are affected by it, but Bitnami just did a major blunder with their Helm repo: bitnami/charts#10539

In essence, they decided to prune to all chart version older than six months from their index....

Just so that I don't forget to add the option to modify the Update Strategy