Overview

Helm2 provided support for the Release namespace {{ .Release.Namespace }} via --namespace option if the release namespace did not exist. This functionality was considered rudimentary, and there were several requests from the community captured in #3503

Helm3 took a more opinionated approach on how to handle --namespace option w/non-existing namespaces by removing support for the release namespace creation. Irrespective of the --namespace option, the {{ .Release.Namespace }} is expected to exist before installing/upgrading any helm chart that utilizes --namespace option.

By dropping support for the Release Namespace creation via --namespace option in Helm3, we also dropped any possibility to install a Helm chart with non-existent namespace! As a result, the chart authors and chart users must rely on additional, external to Helm3 tools like kubectl to
prepare (create) Release Namespace before Helm chart installation.

It is understood that --namespace option to create namespace was sub-optimal in Helm2, which prompted requests from the helm user community similar to #3503.

Proposed Change

Rather than to remove support for the Release Namespace creation altogether, we can provide accommodations for helm chart authors to create the release namespace inline during the helm chart install by allow to define release namespace Inside as a template resource. Moreover, the helm chart authors will also be able to tailor the release namespace to the needs of the applications by including all necessary labels, annotations.

Consider following template for the Release Namespace manifest.

{{- if and .Release.Namespace (.Values.createReleaseNamespace | default false) -}}
apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Release.Namespace }}
  annotations:
    my-annoation: {{ .Values.MyAnnotation }}
  labels:
    release: {{ .Release.Name }}
    my-other-label: other-label
{{- end -}}

In the example above, we chose to emulate current Helm3 chart functionality, i.e., do not create the release namespace by default.

The chart authors can decide whether or not allow multiple instances of their application to target the same namespace. For example, removing {{- if ... end -}} lines, effectively ensure that a given chart can only be installed into a newly created namespace and no two chart instances for this application can share the same namespace.

Processing and Assumptions

While the Release Namespace resource resembles other Helm template resources very closely, the processing of this resource is different.

Helm3 can perform a "special" pre-installation check to see if the Release Namespace is defined in the templates section. If it is - Helm3 will attempt to create the release namespace before recording release history, which utilizes the release namespace.

The "special" handling of the Release Namespace hs following assumptions/implications:

• The release namespace creation will be considered as a "special" functionality, i.e., since it is processed separately from the rest of the template resources (similar to crds)
• The release namespace artifact will be defined in the templates section, thus will be fully rendered just like any other templates resource (unlike crds)
• The release namespace resource will be "immutable," i.e., Helm3 will support only "Create" and "Delete" life-cycle events, and will not support "Update."
• Installing two charts that result in the resource namespace collision will be handled just like any other collision in templates resources.

Input Result Matrix (Helm3 Current)

Note: here and below, Namespace is synonymous to Release Namespace.

Note: in this example for simplicity we assume that all Helm chart artifacts are installed into the Release Namespace

Input Result Matrix (Proposed)

Same use cases as above, but this time with proposed changed and with Helm chart that includes template definition for the Release Namespace.

Summary

The goal of this proposal is to entertain a possibility to provide Helm chart authors with functionality to define and provide support in terms of the properties when it comes down to the Release Namespace artifact.

With this proposal: Helm chart authors can allow users to:

• Install helm chart into an existing namespace (as currently supported)
• Install helm chart into a non-existing namespace (currently not supported)

while maintaining all the current Helm3 chart behaviors when it comes to storing Helm release information.