Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating a PackageRepository to New Location Does Not Always Update Images #1603

Open
nebhale opened this issue Jul 26, 2024 · 2 comments
Open
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed

Comments

@nebhale
Copy link

nebhale commented Jul 26, 2024

What steps did you take:

  1. Publish a Package Repository imgpkg bundle containing a cert-manger Package to location A
  2. Create a PackageRepository on a cluster that points to location A
  3. Create a PackageInstall for the cert-manager package above and validate that the Pod image locations are from quay.io
  4. Relocate the Package Repository imgpkg bundle from location A to location B using impkg copy
  5. Update the existing PackageRepository to point to location B and validate that the Pod image locations are now from location B
  6. Relocate the Package Repository imgpkg bundle from location B to location C using imgpkg copy
  7. Update the existing PackageRepository to point to location C and validate that the Pod image locations are still from location B

What happened:
Upon the first update of the PackageRepository location, the Pod image locations were updated to match the new location. Upon the second update of the PackageRepository location, the Pod image locations were not updated to match the new location.

What did you expect:
I expect that every update of a PackageRepository location updates the Pod image location to match the new PackageRepository location.

Anything else you would like to add:
No

Environment:

  • kapp Controller version (execute kubectl get deployment -n kapp-controller kapp-controller -o yaml and the annotation is kbld.k14s.io/images):
kbld.k14s.io/images: |
  - origins:
    - local:
        path: /home/runner/work/kapp-controller/kapp-controller
    - git:
        dirty: true
        remoteURL: https://github.com/carvel-dev/kapp-controller
        sha: 2a68e24829837e8b2c326f28e75a2f46448dadcb
        tags:
        - v0.53.0
    url: ghcr.io/carvel-dev/kapp-controller@sha256:2368019cd18fdd82c08c48f5ba7cf6c2df50e35d7e92a16ec1f36c97538985f3
  • Kubernetes version (use kubectl version):
Client Version: v1.30.3
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0

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.

@nebhale nebhale added bug This issue describes a defect or unexpected behavior carvel-triage This issue has not yet been reviewed for validity labels Jul 26, 2024
@praveenrewar praveenrewar added carvel-accepted This issue should be considered for future work and that the triage process has been completed and removed carvel-triage This issue has not yet been reviewed for validity labels Jul 28, 2024
@praveenrewar
Copy link
Member

Thank you for the detailed issue @nebhale

@100mik
Copy link
Contributor

100mik commented Aug 2, 2024

This is primarily because kapp-controller caches images based of their sha reference. And this does not change on relocation.
THis leads to the older images being consumed. We need to have some time/location based invalidation logic in vendir so that kapp-controller can benefit from this behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed
Projects
Status: No status
Development

No branches or pull requests

3 participants