kapp-controller with multiple fetches needs to be revisited

[voor]

Describe the problem/challenge you have kapp-controller when there is a single fetch is fairly intuitive and straightforward -- if you pull down a git repo with /stuff/ then you can reference those paths as /stuff/ in later steps. This becomes a lot more complicated when you have multiple fetches, because now it's /0/stuff/ depending on the order it is fetched in. This become excruciating whenever you want to move from a single fetch to multi-fetch.

Describe the solution you'd like Something that could leverage some kind of overlay or ability to have something more straightforward when multi-fetch is employed, especially when someone is migrating from a single fetch to a multi-fetch.

Anything else you would like to add: This issue was created when a new kapp-controller user had no idea that multi-fetch added numbered folders.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[danielhelfand]

Curious if #151 would be helpful here.

[voor]

Curious if #151 would be helpful here.

It would indeed, if you combined this with the acknowledgement fetch operations could be destructive, you could effectively do something like:

fetch:
  - git:
      url: https://github.com/k14s/kapp
      ref: origin/develop
      subPath: examples/gitops/guestbook
      subDirName: "/"
  - http:
      url: https://raw.githubusercontent.com/k14s/kapp/db2cc63e12e988235eb8815af8edc0ca0cfaa79c/examples/simple-app-example/config-1.yml
      sha256: 71b0a2dceb6bb6e7a519d0587abd9400a265cabbe2c084f783df94a92db6d980
      subDirName: "/"
template:
  - ytt: # config-1.yml and all-in-one.yml would both appear in / as a result, but if the git repo had config-1.yml in it then that file would be overwritten.

[github-actions[bot]]

This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.

[voor]

/remove lifecycle-stale

[danielhelfand]

@voor Do you have any preferred UX around this experience? I know we briefly discussed #151 approach but wanted to see if you had other thoughts.

Alternatively, if implementation proves difficult, would better documentation be enough here to satisfy this?

[voor]

subDirName or a similar implementation where you could overlay and provide a path of migration would be the optimal solution.

As a current user of App CRs, I want to add a new fetch without needing to modify the existing ytt paths or sops paths.

[Glythium]

I have a need for multiple fetches of the same type (fetching from multiple Git repositories) to enable cross-organization Ops as well. Currently, we're limited by the way the App's fetch list is written. If we could have multiple fetches, even of the same type, and have them given some managed key like @voor was suggesting with the subDirName. Could we get something like this to satisfy both asks?

fetch:
  - name: first-repo
    type: git
    info: #! I can't think of a good name for this key, but it can be something generic to apply to the other types of fetches
      url: https://github.com/foo.git
      subPath: some/dir
      secretRef:
        name: foo-git-credentials
  - name: second-repo
    type: git
    info:
      url: https://github.com/bar.git
      subPath: another/dir
      secretRef:
        name: git-credentials

Then we could reference each of those directories in the later parts of the App by their names like:

template:
  - ytt:
    paths:
    - first-repo/foo.yaml
    - second-repo/bar.yaml

[neil-hickey]

hey @voor / @Glythium we have implemented https://github.com/vmware-tanzu/carvel-kapp-controller/issues/151. Does it satisfy this issue's use case?

[neil-hickey]

Closing this issue out, we have provided a way to have a better experience with multiple fetches as part of PR https://github.com/vmware-tanzu/carvel-kapp-controller/issues/151

[voor]

Whoops, sorry, never came back to acknowledge that this was being employed successfully.