quarkiverse / quarkus-helm

Quarkus Extension to generate the Helm artifacts
Apache License 2.0
9 stars 8 forks source link

Helm Release Name and Namespace #334

Open ThoSap opened 2 months ago

ThoSap commented 2 months ago

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:

quarkus:
  helm:
    expressions:
      releaseNamespace1:
        expression: "{{ .Release.Namespace }}"
        path: metadata.namespace
      releaseNamespace2:
        expression: "{{ .Release.Namespace }}"
        path: (kind == Deployment).spec.template.metadata.namespace
      releaseInstanceName1:
        expression: "{{ .Release.Name }}"
        path: metadata.name
      releaseInstanceName2:
        expression: "{{ .Release.Name }}"
        path: metadata.labels.'app.kubernetes.io/name'
      releaseInstanceName3:
        expression: "{{ .Release.Name }}"
        path: (kind == Service).spec.selector.'app.kubernetes.io/name'
      releaseInstanceName4:
        expression: "{{ .Release.Name }}"
        path: (kind == Deployment).spec.selector.matchLabels.'app.kubernetes.io/name'
      releaseInstanceName5:
        expression: "{{ .Release.Name }}"
        path: (kind == Deployment).spec.template.metadata.labels.'app.kubernetes.io/name'

To improve this situation, either

  1. Quarkus Helm should provide a dedicated boolean for this functionality as this is probably a common use case

  2. or quarkus.helm.expressions.name should at least support a list of paths (YAMLPath expressions) instead of a single path, the same as quarkus.values.name.paths supports multiple YAMLPath expressions So it could at least look like this:

    quarkus:
    helm:
    expressions:
      releaseNamespace:
        expression: "{{ .Release.Namespace }}"
        paths: metadata.namespace,(kind == Deployment).spec.template.metadata.namespace
      releaseInstanceName:
        expression: "{{ .Release.Name }}"
        paths: metadata.name,metadata.labels.'app.kubernetes.io/name',(kind == Service).spec.selector.'app.kubernetes.io/name',(kind == Deployment).spec.selector.matchLabels.'app.kubernetes.io/name',(kind == Deployment).spec.template.metadata.labels.'app.kubernetes.io/name'
Sgitario commented 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.

ThoSap commented 2 months ago

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.

ThoSap commented 2 months ago

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/

Sgitario commented 2 months ago

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.