Ignore existing resource on install if resource-policy is keep

[vasicvuk]

I wanted to know if there is possibility for Helm install command to ignore existing resource (if already created) if the helm/resource-policy is keep.

Scenario:

1. I created release with Secret containing random generated password. This Secret is marked as resource-policy: keep
2. I deleted release
3. I do helm install with same release name
4. Install ignores existing secret so that all other services are connected to Secret with old password.

The same thing is needed for PVC.

[renatodelgaudio]

I would be interested in the same feature but for a different use case described below:

I am using Istio to introduce smart routing capabilities across multiple versions of the same service.
The concept is based on the idea to have 2 kubernetes deployments objects belonging to two different releases (2 Helm chart) that are both linked to the same kubernetes service object.

The two kuberntes deployments have the same app label but they differ for

1. The deployment name
2. A label associated to each version

Since both deployments have the same app label (app: {{.Chart.Name}}), they can be both linked to the same kuberentes service.
Finally the VirtualService powered by Istio allows to route the traffic to the correct version according to some criteria

Example below:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: {{ .Chart.Name}}-deployment-{{ .Values.app.version }}
  namespace: {{ .Values.namespace }} 
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{.Chart.Name}}
  template:
    metadata:
      labels:
        app: {{.Chart.Name}}
        version: {{ .Values.app.version }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: {{ .Values.container.port }}
---
apiVersion: v1
kind: Service
metadata:
  name: {{.Chart.Name}}-service
  namespace: {{ .Values.namespace }}
spec:
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.container.port }}
      name: http
  selector:
    app: {{.Chart.Name}}`

The kubernetes service name can be the exactly the same and, as such, available in both Helm chart with no difference at all (Notice the the service name template does not contain the version)
The issue occurs when the second version of the chart is installed as Helm is complaining that the service already exists.

If the generated templates from the second chart are installed through basic kubectly apply, there is no issue since kuberntes notices that there are no changes and ignores it.

I guess that it could make sense in Helm having the same behaviour like kubectl. Maybe there could be an ignore option (with a DISCLAIMER ) so that Helm run the generated yaml files regardless the presence of exsting objects.

[vasicvuk]

I don't know why this issue is categorized as question/support since this is more feature request. I guess there is a lot more cases when this feature could be useful.

[renatodelgaudio]

The same issue occurs when I want to implemnt a multi versions feature using the same package with a rolling update policy.
In this case, I don't have 2 helm releases but always the same one that get upgraded time by time.

With this helm package rolling policy, I would run helm upgrade instead of helm install to bring in the second versions.

The issue is that the second chart should ensure that whatever was deployed as part of the first package install, should not be updated by the second package upgrade (actually not as a whole but on selected objects)

The current Helm seems do not support the possibility to ignore the selected objects deployed by Helm as part fo a previous helm install

[ptrovatelli]

any update on this? I would like to have this feature too. It's very common to initialize a secret upon first install and needing to re-use the same secret after.

[novoxd]

+1 please support these feature, our current usage of helm is a little "hacky" without it.

[bacongobbler]

Please feel free to submit a patch. :)

[iirekm]

+1; it would also solve the issue with forever-changing secrets https://github.com/helm/charts/issues/5167

[ptrovatelli]

+1; it would also solve the issue with forever-changing secrets helm/charts#5167

that is exactly my use case with a secret for a dependent chart (like rabbitmq or postgresql). For now I have stopped using the dependent chart secret and created another secret outside of the dependent chart, in my main application chart. The secret is randomly created with the same code copy/pasted from the dependent chart. I have added parameters in that main chart to decide whether we should create or not each secret when installing with helm.
There is a bit of code duplication but it gives total control on the lifecycle of the secrets

[iirekm]

that is exactly my use case with a secret for a dependent chart (like rabbitmq or postgresql).

For now I generate secrets with Ansible k8s module, and pass them to Helm charts. A bit ugly, but works.

[JiayangZhou]

You can use helm lookup function to check if a resource exists, and skip on install
for instance:

{{- if not (lookup "rbac.authorization.k8s.io/v1" "ClusterRole" "" .Values.clusterrole.name) }}
resources template
{{- end}}

make sure the API groups are correctly set.

[samos123]

@JiayangZhou that only works if you aren't using helm template

[gjenkins8]

@JiayangZhou that only works if you aren't using helm template

#8137