✨ Add support for deploying OCI helm charts in OLM v1

[OchiengEd]

• added support for deploying OCI helm charts which sits behind the HelmChartSupport feature gate
• extend the Cache Store() method to allow storing of Helm charts alongside OCI images
• inspect chart archive contents for chart contents

Description

This pull request aims to add logic to OLM v1 for handling OCI Helm chart support. We expect more work to go into this feature as further discussion on this occurs on issue #962 and the Arbitrary Configuration RFC which may inform how values.yml would be passed to Helm charts.

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	fb98756
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/685196a3517be00008429f0f
😎 Deploy Preview	https://deploy-preview-1971--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign thetechnick for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov]

Codecov Report

Attention: Patch coverage is 73.33333% with 48 lines in your changes missing coverage. Please review.

Project coverage is 73.80%. Comparing base (5812c74) to head (fb98756).

Files with missing lines	Patch %	Lines
internal/shared/util/image/helm.go	78.03%	20 Missing and 9 partials ⚠️
internal/operator-controller/applier/helm.go	0.00%	8 Missing and 1 partial ⚠️
internal/shared/util/image/cache.go	82.35%	4 Missing and 2 partials ⚠️
internal/shared/util/image/pull.go	20.00%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1971      +/-   ##
==========================================
- Coverage   73.81%   73.80%   -0.02%     
==========================================
  Files          80       81       +1     
  Lines        7154     7330     +176     
==========================================
+ Hits         5281     5410     +129     
- Misses       1550     1584      +34     
- Partials      323      336      +13     

Flag	Coverage Δ
e2e	42.99% <1.11%> (-1.16%)	⬇️
unit	60.53% <73.33%> (+0.31%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[camilamacedo86]

OH. Great work 🥇

[OchiengEd]

When pulling a Helm chart with a provenance file, at this time we have chosen to skip pulling the layer to the cache filesystem since we have no logic in place at this time to verify the chart integrity.

operator-controller/internal/shared/util/image/helm.go

Lines 62 to 65 in 059008d

	// Ignore the Helm provenance data layer
	if layer.MediaType == registry.ProvLayerMediaType {
	continue
	}

[OchiengEd]

Also added logic to inspect the contents of a .tgz or .tar.gz file to verify it contains of a Helm archive.

operator-controller/internal/shared/util/image/helm.go

Lines 97 to 135 in 059008d

	func inspectChart(data []byte, metadata *chart.Metadata) (chartInspectionResult, error) {
	gzReader, err := gzip.NewReader(bytes.NewReader(data))
	if err != nil {
	return chartInspectionResult{}, err
	}
	defer gzReader.Close()
	report := chartInspectionResult{}
	tarReader := tar.NewReader(gzReader)
	for {
	header, err := tarReader.Next()
	if err == io.EOF {
	if !report.chartfileExists && !report.templatesExist {
	return report, errors.New("neither Chart.yaml nor templates directory were found")
	}
	if !report.chartfileExists {
	return report, errors.New("the Chart.yaml file was not found")
	}
	if !report.templatesExist {
	return report, errors.New("templates directory not found")
	}
	return report, nil
	}
	if strings.HasSuffix(header.Name, filepath.Join("templates", filepath.Base(header.Name))) {
	report.templatesExist = true
	}
	if filepath.Base(header.Name) == "Chart.yaml" {
	report.chartfileExists = true
	if err := loadMetadataArchive(tarReader, metadata); err != nil {
	return report, err
	}
	}
	}
	}

[camilamacedo86]

It is added with the helm chart, but I think it is OK to exist on the default code as well.
@tmshort @thetechnick WDYT?

[camilamacedo86]

Should it not be protected behind the feature flag as well?

[OchiengEd]

The code will be unreachable as a result of the pullChart() function being wrapped around a feature gate. However, if we need to wrap that code as well, feel tree to let me know

operator-controller/internal/shared/util/image/pull.go

Lines 228 to 232 in 9b366d3

	if features.OperatorControllerFeatureGate.Enabled(features.HelmChartSupport) {
	if hasChart(img) {
	return pullChart(ctx, ownerID, srcRef, canonicalRef, imgSrc, cache)
	}
	}

[camilamacedo86]

I believe that all code should be categorised under a flag, allowing us to easily identify the purpose of each specific code for each alpha/beta feature. However, I think we can wait for others' input to see what they think about. My concern is:

What happens if we decide not to use the alpha/beta feature and want to delete it? If we decide not to promote feature A or B. How hard will it be if not all related code is not under the feature flag condition? But others might think that is OK

@perdasilva @tmshort WDYT?

[perdasilva]

Similarly to my comment above about moving the feature flag checks to main, should we refactor this in a way that make the cache configurable as to the different layer media types and how they are handled?

[perdasilva]

actually - the comment is below =P

[OchiengEd]

Learning moment for me here. How have we removed feature gated code that we have decided not to land in the past? Is using the git history to undo code that is associated with a feature gate sufficient or acceptable?

[camilamacedo86]

I think it’d be helpful to keep all changes behind the feature gate clearly wrapped and centralized. That way, it’s easy to track what’s gated just by reading the code—since we’ll likely be iterating over multiple PRs, relying on Git history isn’t ideal.

Totally open to any approach that makes the boundary clear. The primary goal is to maintain cohesion and ensure we all share a common understanding of what lies behind the gate. 😊

[OchiengEd]

Understood. With that being said, from my perspective our options might be:

1. Execute tests with feature gates enabled
2. Extend the cache to allow tests to run even when the feature gate is disabled
3. Don't wrap the Helm logic in the cache Store() method which will allow tests to run even with feature gate disabled

Open to hear any other ideas or if we might have a preference for one of these options over others.

[OchiengEd]

@camilamacedo86 I was able to get a way to wrap the code and allow tests to run without issue. Hopefully that could suffice for now as we deliberate if to land the feature or not.

operator-controller/internal/shared/util/image/cache.go

Lines 137 to 141 in fb98756

	if features.OperatorControllerFeatureGate.Enabled(features.HelmChartSupport) || testing.Testing() {
	if err := storeChartLayer(dest, layer); err != nil {
	return err
	}
	}

[camilamacedo86]

@OchiengEd

Here: https://github.com/operator-framework/operator-controller/pull/1724/files

@perdasilva added a demo and the doc under the docs/draft for another alpha feature
It would be very nice if we could do your demo within and add the doc for that. Such as it was done in this PR. However, I am okay with it being a follow-up.

[OchiengEd]

I would be for adding documentation and a demo as a follow up.

[perdasilva]

We've been trying to put the feature checks in main. Wdyt about refactoring to have another implementation of the BundleToHelmChart converter that accepts chart bundles, or maybe that can route between different bundle types? Then if the feature gate is enabled, use that one?

[OchiengEd]

I do not have any concerns with having feature checks in main. I think that would be the ideal scenario as it would allow for feature-gated functionality to be tested at build time.

Trying to look at the issue from afar, our challenge in this case is we are trying to run tests on a feature gated function, pullChart() while we are not allowing a portion of the code in the cache's Store() method not to run since the feature gate is not enabled. The big question therefore is how do we navigate this quandary?