Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-27169

Incorrect Helm Chart Resolution in Virtual Repo

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Resolution: Deferred
    • Affects Version/s: 7.39.0, 7.38.6
    • Fix Version/s: None
    • Component/s: Artifactory, Helm
    • Labels:
    • Environment:

      I have reproduced this as far back as 7.29.7 and the most recent release of 7.38.10 with both a CentOS RPM installation and a kubernetes helm chart installation.

    • Severity:
      High
    • Location:
      External

      Description

      **Description

      I am seeing some strange and incorrect behavior with a helm virtual repository when a chart seems to exist in multiple remote repositories and one of those remote repositories is Bitnami's helm repository. Even if the Bitnami remote is the last in the list of resolution, the virtual repository still seems to serve up incorrect data from Bitnami even if the file existed in one of the other remotes further up the resolution order.

      Steps to reproduce

      1. Create a remote repository of Elasticsearch's helm repo:
      2. Create a remote repository of Bitnami's helm repo:
      3. Create a virtual repo, helm-virtual, with the following resolution order:
        1. elastic-remote
        2. bitnami-remote
      4. Download a chart version that exists in the elastic-remote repo but not in the bitnami-remote repo.
        • https://<artifactory>/artifactory/api/helm/helm-virtual/helm/elasticsearch/elasticsearch-7.17.3.tgz
      5. When you look at the content of that chart file downloaded, you will see that it is not the file from the first remote in the virtual repo. Instead, it is what appears to be the index.yaml file from the second bitnami-remote repo.
        • Note: Part of this seems to be the behavior of Bitnami. Instead of returning a 404 for non-existent URLs; then seemingly just return the helm repo's index.yaml.
      6. If you download the file from the correct remote repository directly, that works as expected.
        • https://<artifactory>/artifactory/api/helm/elastic-remote/helm/elasticsearch/elasticsearch-7.17.3.tgz

      Expected Behavior

      I would expect that the file downloaded from the virtual repo honors the order specified in the virtual repo, especially when nothing has even been cached locally. In the case of my example steps above, it should have downloaded the file from elastic-remote since it is present there.

      Workaround

      For now, I have found an undesirable workaround. I configure the Bitnami remote to only include the specific charts I'm looking to retrieve from it. For example: mongodb-.tgz or postgresql-.tgz. That seems to be easiest way I found to avoid this issue, but is obviously pretty bad because it requires explicit configuration in Artifactory for exact charts.

      Another workaround can be to mark other remote repositories for priority resolutions except for the bitnami.

        Attachments

          Activity

              People

              Assignee:
              Unassigned
              Reporter:
              krische Brian Krische
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Sync Status

                  Connection: RTFACT Sync
                  RTMID-27233 -
                  SYNCHRONIZED
                  • Last Sync Date: