Helm-operator: Create namespace with Helmrelease

[ferrandinand]

Describe the feature
I would like to be able to create namespaces if it is not already created when defining a HelmRelase CR.

Helm 3.2 allows to create namespaces on the command line following the next convention:
helm install wordpress stable/wordpress --namespace wordpress --create-namespace

A possible helmrelase CR could look like this

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: botkube
  namespace: mynamespace
spec:
  releaseName: botkube
  createNamespace: true 
  chart:
    git: [email protected]:awsopda/helm-charts.git
    path: botkube
    ref: v0.4.1
  values:
    config:
    communications:
        slack:
          enabled: true
          channel: '#deploys'

The status is managed in the controlller and knows if the flag should be appended to the helm command or not.

Links
https://github.com/helm/helm/pull/7648

[stefanprodan]

@ferrandinand a HelmRelease is a namespaced object, you can't create the HR object if the namespace doesn't exists.

[ferrandinand]

Ok I assume that in the way the application works, helm-operator will never be able to install the helmrelease in one namespace(let's say a management namespace) and then the helm installation in a different one.

We can close this issue if you think this is not a possible case.

[nicolasscaerou]

If I understand:
1 - the target namespace for your helmRelease MUST be created so the helmRelease could be applied in this namespace;
2- the helmRelease CAN be in a namespace-1 and the release in a namespace-2 by using spec.targetNamespace; (doc: https://docs.fluxcd.io/projects/helm-operator/en/latest/helmrelease-guide/release-configuration/)

[ferrandinand]

Thanks @nicolasscaerou for the clarification.
@stefanprodan do you think it makes sense to have the possibility to create the namespace for the second option? Maybe using helm --create-namespace flag?

```
2- the helmRelease CAN be in a namespace-1 and the release in a namespace-2 by using spec.targetNamespace

[marratj]

We also do have a use case where we'd like to be able to use option 2:

In a shared cluster:

• create HelmRelease resource tenant1 in existing kube-tenants namespace
• Option --create-namespace would be enabled for this, targetNamespace: tenant1 is set
• the actual Helm release then would be created in the automagically created tenant1 namespace with all the resources defined in the Helm chart for this tenant namespace.
  
  
  
  • this actually includes a namespace-scoped Flux & helm-operator instance for this tenant
  
  
  • and other stuff like Network Policy and Resource Quota
  
  

With that we could remove the intermediate step of creating the tenant namespace before applying the HelmRelease

[ferrandinand]

I feel maintainers are no longer considering this issue as it has wontfix label.
@marratj I would suggest that you reformulate again in a new issue as I see it is a very valid use case.

[stefanprodan]

Creating a namespace on the fly is not something that we are considering. Imagine that namespace needs an annotation or label, like sidecar.istio.io/inject: "true". I think the Helm --create-namespace flag is more of a dev feature than something that you should be using in production.

[varac]

I find the helm --create-namespace incredibly valuable (whether or not it's a dev or production feature could be a controversial discussion) and would love to have the similar functionality for helm-operator. And I guess 90% of the time a simple, non-annotated namespace is sufficient.

[voron]

Helm2 has "create namespace" by default, helm3 re-invented this feature starting from 3.2.
I'm here because I want to create all HelmRelease in single namespace and helm-operator with clusterRole will create all the required namespaces based on targetNamespace then.

[emctl]

Helm2 has "create namespace" by default, helm3 re-invented this feature starting from 3.2.
I'm here because I want to create all HelmRelease in single namespace and helm-operator with clusterRole will create all the required namespaces based on targetNamespace then.

+1