Helm charts define helper templates in _helpers.tpl
which are used to create normalized names for the services. The standard form of the template for a service (DNS
Well this is something that isn't very straight forward somehow.
I think what is going on here are the practices helm follows and what is possible with the templates.
One practice is "charts work out of the box" - so whether its a sub-chart or standalone, it should just work. This has some consequences on what you need to configure to properly namespace the resources you deploy and that are referenced.
I had a very similar issue, see How to reference a value defined in a template in a sub-chart in helm for kubernetes?
My "solution" to this is to re-define the postgres.fullname in my own _helpers.tpl:
{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}
Since release names must be unique per tiller installation - and we have one tiller in the cluster - I sort of took some distance from using the release name as part of the references and and own naming convention.
The defines in the templates are global. So you could just use those if you're good with the release name prefix that defaults the postgres chart:
{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}
I could not come up with release names that would not duplicate service names ("webshop-service-webshop-service") so I tend to not use them since I need them per namespace, not per tiller instance.
Once I define the name from the sub-chart I reference it in my services. I'm ok with it since I know what chart I reference and what it uses for namings. But its true: should I upgrade the sub-chart I need to check if the names are still the same. But since that "fullname" is quite common I think I'm good. And some tests would fail anyway.
But not a beautiful "solution".
Not an answer - just good enough for me :)