Originally you suggest the following syntax to extend default names for different resources:

{{- define "my.fullname" -}}
  {{ template "common.fullname" . }}-my-stuff
{{- end -}}

But this is inconvenient. When you need to refer to different configuration values for different resources, you have to use something like in the DataDog's example:

{{- if .Values.my-chart-app-my-stuff.env }}
{{ toYaml .Values.my-chart-app-my-stuff.env | indent 10 }}
{{- end }}

As you see, the code can't be reused in templates.
But actually there's a trick that may help to make it better. Let's change `common.fullname' a little bit:

{{- define "common.fullname"}}
  {{- $global := default (dict) .Values.global -}}
  {{- $base := default (printf "%s-%s" .Release.Name .Chart.Name) .Values.fullnameOverride -}}
  {{- if (.appName) -}}
    {{- $base = .appName -}}
  {{- else -}}
  {{- end -}}
  {{- $gpre := default "" $global.fullnamePrefix -}}
  {{- $pre := default "" .Values.fullnamePrefix -}}
  {{- $suf := default "" .Values.fullnameSuffix -}}
  {{- $gsuf := default "" $global.fullnameSuffix -}}
  {{- $name := print $gpre $pre $base $suf $gsuf -}}
  {{- $name | lower | trunc 54 | trimSuffix "-" -}}
{{- end -}}

Now it checks if .appName is set in global scope. And now we can set the name differently in different deployments/services/etc:

{{- $_ := set . "appName" "my-chart-app-my-stuff" -}}
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: {{ template "common.fullname" . }}

And in the same time in values.yaml we can set the structure:

resources:
  my-chart-app-my-stuff:
    requests:
      memory: 512Mi
    limits:
      memory: 512Mi

And use it in the same deployment using the .appName:

# ...
          resources:
{{ index .Values "resources" .appName | toYaml | trim | indent 12 }}

So the key difference is that .Values.fullnameOverride can be used for the entire chart but .appName can be set for a specific resource individually which makes templates more clear, reusable and flexible.

P.S.: I know about https://github.com/helm/charts/tree/master/incubator/common but I guess it's better to discuss the chart here than in that repo with tons of issues.

After talking with @technosophos on Slack, it became clear to us that what we're trying to do here leads to some awkward configurations for more complex charts (e.g. see the deployment in https://gist.github.com/prydonius/30747d0bbee3487b1b67b4454d65b423 - there's a mix of stuff in values.yaml and awkward syntax is the deployment itself). It works nice for the simple cases like services, but quickly becomes more difficult if you need to do stuff with values in the resources.

We're thinking it might be better to take a lighter approach, rather than try to abstract away the full Kubernetes objects, we can just create a bunch of helper functions for reducing boilerplate for common snippets like labels, volumes, resources, etc.

Thanks for the great examples and starting spot, this is something I could see being immensely helpful for my team and others on leveraging repeatable templates.

One thing to note, the currently deployed version on https://technosophos.github.io/common-chart/ does not contain the updates that were made to some of the core helpers, so it is a bit disorienting when attempting to follow along with the docs @ https://technosophos.github.io/common-chart/ and not get the desired results.

This is what I did.

1. Followed the instruction to create a new chart

helm create mychart

2. add common

cd mychart/charts
helm fetch common/common

Note that the last command (helm fetch) is different from what is described in the instruction. If I used
helm fetch common
I then got
Error: Non-absolute URLs should be in form of repo_name/path_to_chart, got: common

3. add a some.yaml file under mychart/templates/

{{- template "common.deployment" (list . "mychart.deployment") -}}
{{- define "mychart.deployment" -}}
## Define overrides for your Deployment resource here, e.g.
spec:
  template:
    spec:
      containers:
      - {{ template "common.container" (list . "mychart.deployment.container") }}
{{- end -}}
{{- define "mychart.deployment.container" -}}
## Define overrides for your Container here, e.g.
livenessProbe:
  httpGet:
    path: /
    port: 80
readinessProbe:
  httpGet:
    path: /
    port: 80
{{- end -}}

4. ran this command

helm template --name myrelease mychart

and then got
Error: render error in "mychart/templates/some.yaml": template: mychart/charts/common/templates/_common.tpl:17:27: executing "common.fullname" at <.Release.Name>: can't evaluate field Release in type []interface {}

Question:

Where did I do wrong?

There are a subset of resources that K8 manages where label changes are not allowed, such as StatefulSets. When using the common.labels.standard and similar, one issue that we have run into is the inability to upgrade a version of our Helm chart on an existing deployment.

My suggestion would be that the version should probably be left out of the standard labels & that the chart label strictly refer to the {{.Chart.Name}} and omit the {{.Chart.Version}}