Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8534

Allow to Mirror Helm Charts Which Default Values Files Are Insufficient for Rendering in oc-mirror v2

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • oc-mirror
    • None
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request
      oc-mirror v2: Allow to Mirror Helm Charts Which Default Values Files Are Insufficient for Rendering

      2. What is the nature and description of the request?
      Currently, oc-mirror v2 fails the entire mirroring process when attempting to mirror a Helm chart whose default values.yaml file is insufficient to render the chart template properly. The tool attempts to render the Helm chart during the download/collection phase, and if rendering fails due to missing required template values, the operation terminates with an error.

      Requested Change: Modify oc-mirror v2 to handle Helm chart rendering failures gracefully by either:

      • Treating chart rendering errors as warnings instead of blocking errors, allowing the mirroring process to continue and complete successfully
      • Skipping the chart rendering/validation step entirely during the mirror collection phase
      • Making chart rendering optional via a configuration flag or command-line option
      • This would allow users to mirror Helm charts that have non-default or conditional value requirements without being forced to provide a complete, valid values file during the mirror operation.

      3. Why does the customer need this? (List the business requirements here)

      Production Readiness: The inability to mirror valid, published Helm charts (such as CyberArk's Conjur chart) creates operational friction and limits the utility of oc-mirror for enterprise environments where chart flexibility is required.

      Third-Party Chart Control: For many Helm charts, organizations have no control over the chart design or default values—these are maintained by external vendors and open-source projects. Users should not be blocked from mirroring these charts due to rendering requirements they cannot modify.

      Separation of Concerns: Chart rendering and validation should occur at deployment time (when helm install is run with user-provided values), not at mirror collection time. oc-mirror's responsibility is to mirror chart artifacts, not to act as a Helm linting or validation tool.

      4. List any affected packages or components.

      Package: oc-mirror v2 and later

      Component: Helm chart collection and mirroring functionality

      Specific file: https://github.com/openshift/oc-mirror/blob/1d7329e14f2f8986c89ec5805cb23f88a77db463/v2/internal/pkg/helm/local_stored_collector.go#L405

              rhn-support-mkalinin Marina Kalinin
              rhn-support-suc SUYAMBULINGAM C
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                None
                None