Rendered Manifests Contain a Resource That Already Exists on Zarf Package Deploy

[anthonywendt]

Environment

Device and OS: ec2 Ubuntu
App version: v.0.25.0
Kubernetes distro being used: kind v0.17.0

Steps to reproduce

I was testing the Jira backup/restore feature in DI2ME. While deploying the day2 restore package I ran into this issue where the repository had force pushed branches and zarf didn't like that.
Output from that:

📦 SETUP COMPONENT                                                                   
                                                                                       

  •  Loading the Zarf State from the Kubernetes cluster
  •  Loading the Zarf State from the Kubernetes cluster
  •  Opening tunnel 37371 -> 3000 for svc/zarf-gitea-http in namespace zarf
  •  Creating port forwarding tunnel at http://127.0.0.1:37371/
  •  Processing git repo https://github.com/defenseunicorns/zarf-package-software-factory.git
 WARNING  Unable to push the git repo zarf-package-software-factory (unable to push repo to the gitops
          service: non-fast-forward update:
          refs/heads/renovate/https-github.com-jenkinsci-helm-charts.git-4.x). Retrying....
  •  Opening tunnel 35293 -> 3000 for svc/zarf-gitea-http in namespace zarf
  •  Creating port forwarding tunnel at http://127.0.0.1:35293/
  •  Processing git repo https://github.com/defenseunicorns/zarf-package-software-factory.git
 WARNING  Unable to push the git repo zarf-package-software-factory (unable to push repo to the gitops
          service: non-fast-forward update:
          refs/heads/renovate/https-github.com-jenkinsci-helm-charts.git-4.x). Retrying....
  •  Opening tunnel 44677 -> 3000 for svc/zarf-gitea-http in namespace zarf
  •  Creating port forwarding tunnel at http://127.0.0.1:44677/
  •  Processing git repo https://github.com/defenseunicorns/zarf-package-software-factory.git
 WARNING  Unable to push the git repo zarf-package-software-factory (unable to push repo to the gitops
          service: non-fast-forward update:
          refs/heads/renovate/https-github.com-jenkinsci-helm-charts.git-4.x). Retrying....
     ERROR:  Failed to deploy package: unable to deploy all components in this Zarf Package: unable to deploy
             component setup: unable to push the repos to the repository: unable to push repo
             https://github.com/defenseunicorns/zarf-package-software-factory.git to the Git Server: unable to
             push repo to the gitops service: non-fast-forward update:
             refs/heads/renovate/https-github.com-jenkinsci-helm-charts.git-4.x

In an effort to work around this issue, I tried creating a new Zarf package with a repo url using the RefSpec pointing to a specific branch. I then tried to zarf deploy that new package to the same cluster that gave me the error above. I then got this new error.
New Error:

WARNING  Unable to complete helm chart install/upgrade, waiting 10 seconds and trying again
DEBUG   2023-03-27T22:56:58Z  -  rendered manifests contain a resource that already exists. 
Unable to continue with install: GitRepository "zarf-package-software-factory" in namespace "flux-system" exists and cannot be
imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must 
equal "zarf-77ebb5d16d41e85ceb2036ad2e264187423b4111": current value is "zarf-53f8d5dd511e7b9b04b69a33b39271d5f8d8c139"

The ZarfPackageConfig that was being deployed both times. The second one just used a different repo url containing the RefSpec to a branch.

kind: ZarfPackageConfig
metadata:
  name: day-two-update

components:
  - name: setup
    required: true
    repos:
      - "###ZARF_PKG_VAR_DI2ME_REPO###"
    manifests:
      - name: setup-config
        files:
          - ../manifests/setup.yaml
  - name: postgres-operator
    required: true
    manifests:
      - name: postgres-operator-config
        files:
          - ../manifests/postgres-operator.yaml
  - name: gitlab-redis
    required: true
    manifests:
      - name: gitlab-redis-config
        files:
          - ../manifests/gitlab-redis.yaml
  - name: big-bang
    required: true
    manifests:
      - name: big-bang-config
        files:
          - ../manifests/big-bang.yaml
  - name: softwarefactoryaddons
    required: true
    manifests:
      - name: softwarefactoryaddons-config
        files:
          - ../manifests/softwarefactoryaddons.yaml

Expected result

Should Zarf be able to handle resources in packages that may already exist? It was an attempt to re deploy with a small update to a single component after the first deploy failed because of a different issue.

Actual result

The second error mentioned.

[Racer159]

Currently zarf hashes the config name, the component name and manifest name together when determining how to generate a chart: https://github.com/defenseunicorns/zarf/blob/f612a0b1dce856da70b756b8e83e523022d77241/src/internal/packager/helm/chart.go#L204

Most likely this is because day-two-update doesn't match the original package name.

[anthonywendt]

So to deploy an update to an already deployed Zarf package, the name of the package needs to match? Just double checking I understand that correctly.

Update: Using the same package name as what was originally deployed worked for me

[anthonywendt]

Closing this issue