fix: bring back Release.Namespace

any chart which uses `RoleBinding` or `ClusterRoleBinding` needs a way to populate the namespace being used for a release - such as to reference a `ServiceAccount` in a `RoleBinding`. Removing support for `Release.Namespace` breaks many charts.

Given the namespace being used to install/update a chart is typically fixed; am not sure there's a great reason for its removal - as its totally repeatable.

fixes #4255

cmd/helm/template.go

@@ -165,7 +165,8 @@ func (o *templateOptions) run(out io.Writer) error {
 		return errors.Wrap(err, "cannot load requirements")
 	}
 	options := chartutil.ReleaseOptions{
-		Name: o.releaseName,
+		Name:      o.releaseName,
+		Namespace: getNamespace(),
 	}
 
 	if err := chartutil.ProcessRequirementsEnabled(c, config); err != nil {

cmd/helm/testdata/output/template-absolute.txt

@@ -6,6 +6,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template-kube-version.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "6"

cmd/helm/testdata/output/template-name-template.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "foobar-YWJj-baz"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template-name.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "test"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template-notes.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template-set.txt

@@ -6,6 +6,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template-values-files.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "9"

cmd/helm/testdata/output/template.txt

@@ -42,6 +42,7 @@ metadata:
   name: subchart1
   labels:
     chart: "subchart1-0.1.0"
+    namespace: "default"
     release-name: "RELEASE-NAME"
     kube-version/major: "1"
     kube-version/minor: "9"

docs/chart_template_guide/builtin_objects.md

@@ -8,6 +8,7 @@ In the previous section, we use `{{.Release.Name}}` to insert the name of a rele
 
 - `Release`: This object describes the release itself. It has several objects inside of it:
   - `Release.Name`: The release name
+  - `Release.Namespace`: The namespace to be released into (if the manifest doesn't override)
   - `Release.Service`: The name of the releasing service (always `Tiller`).
   - `Release.IsUpgrade`: This is set to `true` if the current operation is an upgrade or rollback.
   - `Release.IsInstall`: This is set to `true` if the current operation is an install.

docs/charts.md

@@ -141,9 +141,9 @@ for greater detail.
 
 ## Chart Dependencies
 
-In Helm, one chart may depend on any number of other charts.
+In Helm, one chart may depend on any number of other charts. 
 These dependencies can be dynamically linked through the `requirements.yaml`
-file or brought in to the `charts/` directory and managed manually.
+file or brought in to the `charts/` directory and managed manually. 
 
 Although manually managing your dependencies has a few advantages some teams need,
 the preferred method of declaring dependencies is by using a
@@ -290,11 +290,11 @@ tags:
 
 In the above example all charts with the tag `front-end` would be disabled but since the
 `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the
-`front-end` tag and `subchart1` will be enabled.
+`front-end` tag and `subchart1` will be enabled.  
 
 Since `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be
 enabled. Also notes that although `subchart2` has a condition specified in `requirements.yaml`, there
-is no corresponding path and value in the parent's values so that condition has no effect.
+is no corresponding path and value in the parent's values so that condition has no effect.  
 
 ##### Using the CLI with Tags and Conditions
 
@@ -317,19 +317,19 @@ helm install --set tags.front-end=true --set subchart2.enabled=false
 
 #### Importing Child Values via requirements.yaml
 
-In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be
+In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be 
-shared as common defaults. An additional benefit of using the `exports` format is that it will enable future
+shared as common defaults. An additional benefit of using the `exports` format is that it will enable future 
 tooling to introspect user-settable values.
 
-The keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file
+The keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file 
-using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field.
+using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field. 
 
 To import values not contained in the `exports` key, use the [child-parent](#using-the-child-parent-format) format.
 Examples of both formats are described below.
 
 ##### Using the exports format
 
-If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported
+If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported 
 directly into the parent's values by specifying the keys to import as in the example below:
 
 ```yaml
@@ -346,8 +346,8 @@ exports:
     myint: 99
 ```
 
-Since we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child
+Since we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child 
-chart for `data` key and imports its contents.
+chart for `data` key and imports its contents. 
 
 The final parent values would contain our exported field:
 
@@ -358,16 +358,16 @@ myint: 99
 
 ```
 
-Please note the parent key `data` is not contained in the parent's final values. If you need to specify the
+Please note the parent key `data` is not contained in the parent's final values. If you need to specify the 
-parent key, use the 'child-parent' format.
+parent key, use the 'child-parent' format. 
 
 ##### Using the child-parent format
 
-To access values that are not contained in the `exports` key of the child chart's values, you will need to
+To access values that are not contained in the `exports` key of the child chart's values, you will need to 
-specify the source key of the values to be imported (`child`) and the destination path in the parent chart's
+specify the source key of the values to be imported (`child`) and the destination path in the parent chart's 
 values (`parent`).
 
-The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them
+The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them 
 to the parent's values at the path specified in `parent:`
 
 ```yaml
@@ -382,7 +382,7 @@ dependencies:
         parent: myimports
 ```
 In the above example, values found at `default.data` in the subchart1's values will be imported
-to the `myimports` key in the parent chart's values as detailed below:
+to the `myimports` key in the parent chart's values as detailed below: 
 
 ```yaml
 # parent's values.yaml file
@@ -391,7 +391,7 @@ myimports:
   myint: 0
   mybool: false
   mystring: "helm rocks!"
-
+  
 ```
 ```yaml
 # subchart1's values.yaml file
@@ -400,7 +400,7 @@ default:
   data:
     myint: 999
     mybool: true
-
+    
 ```
 The parent chart's resulting values would be:
 
@@ -468,7 +468,7 @@ Furthermore, A is dependent on chart B that creates objects
 - replicaset "B-ReplicaSet"
 - service "B-Service"
 
-After installation/upgrade of chart A a single Helm release is created/modified. The release will
+After installation/upgrade of chart A a single Helm release is created/modified. The release will 
 create/update all of the above Kubernetes objects in the following order:
 
 - A-Namespace
@@ -478,16 +478,16 @@ create/update all of the above Kubernetes objects in the following order:
 - A-Service
 - B-Service
 
-This is because when Helm installs/upgrades charts,
+This is because when Helm installs/upgrades charts, 
-the Kubernetes objects from the charts and all its dependencies are
+the Kubernetes objects from the charts and all its dependencies are 
 
-- aggregrated into a single set; then
+- aggregrated into a single set; then 
-- sorted by type followed by name; and then
+- sorted by type followed by name; and then 
-- created/updated in that order.
+- created/updated in that order. 
 
 Hence a single release is created with all the objects for the chart and its dependencies.
 
-The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go
+The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go 
 (see [the Helm source file](https://github.com/kubernetes/helm/blob/master/pkg/tiller/kind_sorter.go#L26)).
 
 ## Templates and Values
@@ -574,6 +574,7 @@ cannot be overridden. As with all values, the names are _case
 sensitive_.
 
 - `Release.Name`: The name of the release (not the chart)
+- `Release.Namespace`: The namespace the chart was released to.
 - `Release.Service`: The service that conducted the release. Usually
   this is `Tiller`.
 - `Release.IsUpgrade`: This is set to true if the current operation is an upgrade or rollback.

pkg/chartutil/create.go

@@ -243,16 +243,16 @@ const defaultNotes = `1. Get the application URL by running these commands:
   http{{ if $.Values.ingress.tls }}s{{ end }}://{{ . }}{{ $.Values.ingress.path }}
 {{- end }}
 {{- else if contains "NodePort" .Values.service.type }}
-  export NODE_PORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services {{ template "<CHARTNAME>.fullname" . }})
+  export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ template "<CHARTNAME>.fullname" . }})
-  export NODE_IP=$(kubectl get nodes -o jsonpath="{.items[0].status.addresses[0].address}")
+  export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
   echo http://$NODE_IP:$NODE_PORT
 {{- else if contains "LoadBalancer" .Values.service.type }}
      NOTE: It may take a few minutes for the LoadBalancer IP to be available.
            You can watch the status of by running 'kubectl get svc -w {{ template "<CHARTNAME>.fullname" . }}'
-  export SERVICE_IP=$(kubectl get svc {{ template "<CHARTNAME>.fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
+  export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ template "<CHARTNAME>.fullname" . }} -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   echo http://$SERVICE_IP:{{ .Values.service.port }}
 {{- else if contains "ClusterIP" .Values.service.type }}
-  export POD_NAME=$(kubectl get pods -l "app={{ template "<CHARTNAME>.name" . }},release={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
+  export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "app={{ template "<CHARTNAME>.name" . }},release={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
   echo "Visit http://127.0.0.1:8080 to use your application"
   kubectl port-forward $POD_NAME 8080:80
 {{- end }}

pkg/chartutil/testdata/subpop/charts/subchart1/templates/service.yaml

@@ -4,6 +4,7 @@ metadata:
   name: {{ .Chart.Name }}
   labels:
     chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
+    namespace: "{{ .Release.Namespace }}"
     release-name: "{{ .Release.Name }}"
     kube-version/major: "{{ .Capabilities.KubeVersion.Major }}"
     kube-version/minor: "{{ .Capabilities.KubeVersion.Minor }}"

pkg/chartutil/values.go

@@ -21,7 +21,6 @@ import (
 	"io/ioutil"
 	"log"
 	"strings"
-
 	"github.com/ghodss/yaml"
 	"github.com/pkg/errors"
 
@@ -334,6 +333,7 @@ func coalesceTables(dst, src map[string]interface{}) map[string]interface{} {
 // for the composition of the final values struct
 type ReleaseOptions struct {
 	Name      string
+	Namespace string
 	IsUpgrade bool
 	IsInstall bool
 }
@@ -357,6 +357,7 @@ func ToRenderValuesCaps(chrt *chart.Chart, chrtVals []byte, options ReleaseOptio
 	top := map[string]interface{}{
 		"Release": map[string]interface{}{
 			"Name":      options.Name,
+			"Namespace": options.Namespace,
 			"IsUpgrade": options.IsUpgrade,
 			"IsInstall": options.IsInstall,
 			"Service":   "Helm",

pkg/chartutil/values_test.go

@@ -103,6 +103,7 @@ where:
 
 	o := ReleaseOptions{
 		Name:      "Seven Voyages",
+		Namespace: "al Basrah",
 		IsInstall: true,
 	}
 

pkg/lint/rules/template.go

@@ -50,7 +50,7 @@ func Templates(linter *support.Linter, values []byte, namespace string, strict b
 		return
 	}
 
-	options := chartutil.ReleaseOptions{Name: "testRelease"}
+	options := chartutil.ReleaseOptions{Name: "testRelease", Namespace: namespace}
 	caps := &chartutil.Capabilities{
 		APIVersions: chartutil.DefaultVersionSet,
 		KubeVersion: chartutil.DefaultKubeVersion,

pkg/tiller/release_install.go

@@ -69,6 +69,7 @@ func (s *ReleaseServer) prepareRelease(req *hapi.InstallReleaseRequest) (*releas
 	ts := time.Now()
 	options := chartutil.ReleaseOptions{
 		Name:      name,
+		Namespace: req.Namespace,
 		IsInstall: true,
 	}
 	valuesToRender, err := chartutil.ToRenderValuesCaps(req.Chart, req.Values, options, caps)

pkg/tiller/release_update.go

@@ -98,6 +98,7 @@ func (s *ReleaseServer) prepareUpdate(req *hapi.UpdateReleaseRequest) (*release.
 	ts := time.Now()
 	options := chartutil.ReleaseOptions{
 		Name:      req.Name,
+		Namespace: currentRelease.Namespace,
 		IsUpgrade: true,
 	}