Open ThoSap opened 2 months ago
Another idea is to configure the https://quarkus.io/guides/all-config.html#quarkus-core_quarkus-application-name when building your services and hence generating the helm charts.
About the proposed improment, the second approach sounds good to me +1. If you have already something in mind, feel free to propose an implementation for it.
I'm aware that it is possible to change the application name using this property.
In my case, the quarkus.application.name
is fixed and should be fixed.
I'm deploying multiple Helm instances, each having a completely different values.yaml
configuration for the same Helm chart generated by Quarkus Helm, using the same namespace for multiple prod instances (and a second namespace with all test instances).
Inside one of these namespaces, I must use unique Helm release instance, Deployment, Pod, Service, and Ingress names; hence, I had to add those expressions above.
I meant that this could be a common use case, as these two special Release
object variables .Release.Namespace
and .Release.Name
are part of the built-in Helm objects and are not configured in the values.yaml
file.
https://helm.sh/docs/chart_template_guide/builtin_objects/
Yes, the extension should support the Release object +1. It needs to make clear in the documentation where the name and namespace come from, since we have a few properties from Quarkus, Quarkus Kubernetes and this extension for the same purpose.
I have the following use case. I have multiple deployments of the same service with different configurations, which automatically should use the selected Helm K8s release namespace (
.Release.Namespace
) and Helm release name (.Release.Name
).For this, I added the following Quarkus Helm expressions:
To improve this situation, either
Quarkus Helm should provide a dedicated boolean for this functionality as this is probably a common use case
or
quarkus.helm.expressions.name
should at least support a list ofpaths
(YAMLPath expressions) instead of a singlepath
, the same asquarkus.values.name.paths
supports multiple YAMLPath expressions So it could at least look like this: