Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm Release Name and Namespace #334

Open
ThoSap opened this issue Apr 24, 2024 · 4 comments
Open

Helm Release Name and Namespace #334

ThoSap opened this issue Apr 24, 2024 · 4 comments

Comments

@ThoSap
Copy link

ThoSap commented Apr 24, 2024

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
Copy link
Contributor

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
Copy link
Author

ThoSap commented Apr 24, 2024

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
Copy link
Author

ThoSap commented Apr 24, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants