kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
# helm version
version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}
helm install ldab0ef8b --set ingress.hostname=55974e94-d909-4a8f-be5f-44ccc349dce2.kubernetes.local,extraEnv[0].name=WORDPRESS_URL,extraEnv[0].value=55974e94-d909-4a8f-be5f-44ccc349dce2.kubernetes.local,externalDatabase.host=hosting-mariadb.databases.svc.cluster.local,externalDatabase.port=3306,externalDatabase.user=root,externalDatabase.password=root,externalDatabase.database=993e718b94164d618af2965a461fe8c1 -f /helm/wordpress/values.yaml stable/wordpress 2>&1
after running this it creates deployment with
MARIADB_PORT_NUMBER=%!s(int64=3306)
expected
MARIADB_PORT_NUMBER=3306
What version of the chart is installed? Use helm ls to find out
Looks like this started to happen after https://github.com/helm/charts/pull/21099 was merged @juan131 @javsalgar @carrodher
```
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
u9d595e15-cce8-4595-91bf-0b1b8196a6d8 97ad778d-0659-4fca-9d6a-1c0cdc5ecc31 1 2020-03-01 16:33:25.051127861 +0000 UTC deployed wordpress-9.0.0 5.3.2
Hi everyone,
Please correct me if I'm wrong but you're using the parameters below:
(...)
--set externalDatabase.host=hosting-mariadb.databases.svc.cluster.local \
--set externalDatabase.port=3306 \
--set externalDatabase.user=root \
--set externalDatabase.password=root \
--set externalDatabase.database=993e718b94164d618af2965a461fe8c1
However, you're not using --set mariadb.enabled=false. Therefore, all the parameters that affect the external database will be ignored.
Regarding the issue, I'm unable to reproduce it. See:
$ helm template wordpres \
--set externalDatabase.host=foo \
--set externalDatabase.port=3306 \
--set externalDatabase.user=root \
--set externalDatabase.password=root \
--set externalDatabase.database=wp_db \
--set mariadb.enabled=false stable/wordpress
(...)
# Source: wordpress/templates/deployment.yaml
(...)
env:
- name: ALLOW_EMPTY_PASSWORD
value: "yes"
- name: MARIADB_HOST
value: "foo"
- name: MARIADB_PORT_NUMBER
value: "3306"
- name: WORDPRESS_DATABASE_NAME
value: "wp_db"
- name: WORDPRESS_DATABASE_USER
value: "root"
- name: WORDPRESS_DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: wordpres-externaldb
key: db-password
I can confirm the issue with disabling the external database. Here is my (redacted) values.yaml :
mariadb:
enabled: false
externalDatabase:
host: xxx.xxx.xxx.xxx
user: xxxxx
password: "xxxxx"
database: xxxxx
port: 14948
And when installing, with Helm3, the output of the wordpress pod is :
```
Welcome to the Bitnami wordpress container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-wordpress
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-wordpress/issues
Send us your feedback at [email protected]
WARN ==> You set the environment variable ALLOW_EMPTY_PASSWORD=yes. For safety reasons, do not use this flag in a production environment.
nami INFO Initializing apache
nami INFO apache successfully initialized
nami INFO Initializing php
nami INFO php successfully initialized
nami INFO Initializing mysql-client
nami INFO mysql-client successfully initialized
nami INFO Initializing wordpress
wordpre INFO ==> Preparing Varnish environment
wordpre INFO ==> Preparing Apache environment
wordpre INFO ==> Preparing PHP environment
mysql-c INFO Trying to connect to MySQL server
Error executing 'postInstallation': "port" option should be >= 0 and < 65536: %!s(float64=14948)```
And the pod goes into error
And switching to chart 8.1.5 works
Oh I found the error! Creating a PR to address it!
Thanks for reporting it
Thanks @juan131 !
The issue has been addressed in the above PR. You shouldn't face it anymore using the chart version 9.0.1
Most helpful comment
Thanks @juan131 !