`${gravitee.home}` is not used in the volumeMounts properties of the `api-deployment.yaml`

[apoddany]

Describe the bug

On apim3-3.1.32 version in the api-configmap.yaml, $

{gravitee.home} is used to set the base directory to load the templates from. The same is done also in the api-deployment.yaml file to load the gravitee plugins.

But the ${gravitee.home}

is not used in the volumeMounts properties of the api-deployment.yaml instead of the hardcoded value

• name: config mountPath: /opt/graviteeio-management-api/config/gravitee.yml subPath: gravitee.yml {{- if .Values.api.logging.debug }}
• name: config mountPath: /opt/graviteeio-management-api/config/logback.xml subPath: logback.xml {{- end }} {{- if and .Values.jdbc.driver (eq .Values.management.type "jdbc") }}
• name: graviteeio-apim-repository-jdbc-ext mountPath: /opt/graviteeio-management-api/plugins/ext/repository-jdbc

https://github.com/gravitee-io/helm-charts/blob/ef7953ffddc97212787f2fd0fae967970c339fa2/apim/3.x/templates/api/api-deployment.yaml#L142

The same appears for the gateway-deployment.yaml configuration

[gaetanmaisse]

Instead of using an environment variable (+ subPathExpr, see https://stackoverflow.com/a/64593803/4069646) we could define and use a Value to make /opt/graviteeio-management-api configurable.

But we want to give such flexibility in our Charts vs maintenance? What's your thoughts about that @gravitee-io/archi ?

[guillaumelamirand]

configMap is used to generate gravitee.yml and so the ${gravitee.home} declared inside it is not resolved by the helmchart but by the application itself. This is currently no option to customize the gravitee.home when using Helm chart.

We agreed on we may not want to customize the gravitee.home, however as the customer is already doing so and in order to answer his need, we need to update the helm chart by :

1. Adding a new Value for gravitee.home in the Values file, default value should be the one currently used
2. Updating deployment to create a GRAVITEE_HOME env variable inside pods from the new value
3. Entrypoint sh shouldn't require any change as it is already checking for any GRAVITEE_HOME env variable before setting it

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gaetanmaisse]

After a discussion with @sebdevaux and @passionne to check the solution provided by the user (use ${gravitee.home} in volumeMounts), it looks like it cannot work as the environment variables are for the process running in the container and not evaluated at deployment time.

An option would be to rely on https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath-expanded-environment, but it doesn't really fit with ${gravitee.home}.

So, as stated here and here the only way to handle the request asked by the user would be by introducing new values to set the folder path during the deployment. However, it would add some complexity to our Helm chart to support custom docker images (as the official ones are compatible), which we're not keen to do.