Support deployment to a namespace

[mrsimonemms]

The charts didn't specify metadata.namespace anywhere so have added support for this. Have used the {{ .Release.Namespace }} variable which defaults to default if not set. This makes it a non-intrusive change for anyone not wanting to use it, but a useful change for those who do

Fixed #41

Have tested against my own cluster with these commands:

Default namespace

helm upgrade \
  --atomic \
  --cleanup-on-fail \
  --install \
  --wait \
  registry .

This deploys registry to default namespace

Custom namespace

helm upgrade \
  --atomic \
  --cleanup-on-fail \
  --create-namespace \
  --install \
  --namespace registry \
  --wait \
  registry .

This deploys registry to registry namespace

[canterberry]

To install a Helm chart into a specific namespace, can you not pass --namespace ... to the helm install/upgrade command? This should, in theory, install all resources to that namespace, as well as the Helm release metadata. If my understanding is correct, the changeset should be a no-op (i.e: since it reflects the default behavior anyway). If the chart currently just installs resources to the default namespace anyway, though, that's certainly undesirable!

In all the Helm charts I have written, I have done as you have proposed in this changeset, so I am inclined to approve. Regardless of whether my assumption above is correct regarding the default behavior, I do think being explicit about the namespace is an improvement.

However, I've read that having the resource namespace match the release metadata namespace is not always desirable. Helm release secrets do accumulate over time, polluting the release namespace. To split that, you'd have essentially the same changeset as here, but {{ .Values.namespace | default .Release.Namespace }}, and introduce an optional namespace value that chart users can set if desired. That solution, I think, would take care of all desired namespacing scenarios.

[mrsimonemms]

@canterberry specifying --namespace may well work with you're using it with helm install or helm upgrade, but it doesn't seem to work with helm template which is my specific use-case - see gitpod/installer for more details.

I've not come across what you've said about the resource/release namespace matching not being desirable, but I can see that it could be a problem with a library. I'll make the change you suggested and document it in the values.yaml

[mrsimonemms]

@canterberry apologies, I hadn't signed the commit - done now

[canterberry]

Released in v1.15.0.