DISCOURSE_REDIS_USE_SSL default misbehaving

[djetelina]

Name and Version

bitnami/discourse 3.2.2

What architecture are you using?

amd64

What steps will reproduce the bug?

1. Install the discourse chart from bitnami charts with defaults
2. discourse won't be able to connect to redis, it will try to use ssl connection

What is the expected behavior?

Default "no" should evaluate as false and use non-ssl connection to redis

What do you see instead?

Somewhere along the way the variable evaluates truthy. Overriding the dafault with false fixes the issue.

Additional information

Original discovery can be found here: bitnami/charts#27476

I wanted to commit a PR, but I'll be honest, I can't see the mistakes that's causing this. The following line (262) in libdiscourse.sh:

is_boolean_yes "$DISCOURSE_REDIS_USE_SSL" && discourse_conf_set "redis_use_ssl" true

is editing the config file only if is_boolean_yes is truthy. Which it's not. So I'm not quite sure what's happening here.

The only fix I can manage is changing the default fallback for the env variable to false, but that goes against the standards as discussed in #4174 which probably introduced this issue.

So the question is, what am I not seeing? I'd really like to contribute a proper fix :)

[fmulero]

Hi @djetelina thanks for using bitnami/charts and trying to fix this problem.

I'd like to go to the basics, because I am not able to reproduce your issue. How did you find the issue? Could you share logs or
any evidence of the problem? These are the steps I followed with version 13.2.6:

# I disabled the livenessProbe because the initial load (database initialization and plugin compilation) it was taking more than expected 
$ helm install discourse bitnami/discourse --set discourse.livenessProbe.enabled=false
NAME: discourse
LAST DEPLOYED: Tue Jul  2 12:35:25 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: discourse
CHART VERSION: 13.2.6
APP VERSION: 3.2.2
** Please be patient while the chart is being deployed **Discourse can be accessed via port 80 on the following DNS name from within your cluster:

    discourse.default.svc.cluster.local

To connect to Discourse from outside the cluster, perform the following steps:

1.  Create a port-forward to the service:

    kubectl port-forward --namespace default svc/discourse 80:80 &
    echo "Discourse URL: http://127.0.0.1:80"

2. Open a browser and access Discourse using the obtained URL.

3. Get your Discourse login credentials by running:

    export DISCOURSE_PASSWORD=$(kubectl get secret --namespace "default" discourse-discourse -o jsonpath="{.data.discourse-password}" | base64 -d)
    echo User:     user
    echo Password: $DISCOURSE_PASSWORD

WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. For production installations, please set the following values according to your workload needs:
  - discourse.resources
  - sidekiq.resources
+info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

In my case, the Initialization process took around 6 min, after that I could login in to the application and use it without issues

[djetelina]

That's even more strange, so the issue has more to do with our environment than I thought. The environment and values are present in the charts issue I linked. Butw how does any of this make sense and what could even be wrong with the env that it's misbehaving in this way - I don't know.

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.