✨ 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	02f39cc
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/6865462add8e2f0008c3a386
😎 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.

[codecov]

Codecov Report

Attention: Patch coverage is 78.57143% with 36 lines in your changes missing coverage. Please review.

Project coverage is 74.74%. Comparing base (22a990c) to head (02f39cc).
Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/shared/util/image/cache.go	70.58%	10 Missing and 5 partials ⚠️
internal/shared/util/image/helm.go	89.32%	7 Missing and 4 partials ⚠️
internal/operator-controller/applier/helm.go	22.22%	6 Missing and 1 partial ⚠️
internal/shared/util/image/pull.go	40.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1971 +/- ##
==========================================
+ Coverage 74.66% 74.74% +0.07% 
==========================================
Files 81 82 +1 Lines 7365 7530 +165 ==========================================
+ Hits 5499 5628 +129 - Misses 1528 1553 +25 - Partials 338 349 +11 

Flag	Coverage Δ
e2e	43.12% <3.57%> (-0.94%)	⬇️
experimental-e2e	49.19% <13.09%> (-0.90%)	⬇️
unit	60.57% <75.00%> (+0.32%)	⬆️

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
	iflayer.MediaType==registry.ProvLayerMediaType {
	continue
	}

[joelanford]

I may have mentioned this elsewhere. If I did, apologies for repeating myself...

I feel like a better way of handling this would be to register handlers for media types. Then this section of the code would lookup the media type of the layer and then call whatever handler is found (or error if there isn't one).

With that setup, the registration of the helm chart media type/handler would be feature gated, but this code would not.

[OchiengEd]

Code has been refactored. Hopefully I got your suggestion right.

[joelanford]

It still isn't exactly what I have in mind. What I have in mind is that ContainersImagePuller would have a new field named ImageHandlers that would represent the kinds of images that can be pulled. So we'd have an ImageHandler for registry+v1 and one for helm charts, and we would register those appliers in main.go (where the helm image applier would be registered behind a feature gate).

The ImageHandler could be an interface something like this:

typeImageHandlerinterface {
Match(ctx context.Context, img types.ImageCloser) (bool, error) // likely just needs `img.Manifest()`Apply(ctx context.Context, ownerIDstring, srcRef reference.Named, canonicalRef reference.Canonical, imgSrc types.ImageSource, cacheCache, sourceContext*types.SystemContext) (fs.FS, time.Time, error)

With that, ContainersImagePuller.applyImage could iterate the handlers looking for the first matching handler, and then call that handler's Apply method. And then the ContainersImagePuller implementation wouldn't have to concern itself with the details of every single image type we ever want to support.

[camilamacedo86]

Thank you a lot for your contribution 🥇
I’m OK with the changes 👍 Well done 🎉
/lgtm

IHMO: It is an initial implementation, and as follow-up, I think we need to do:

• Documentation (docs/draft) and a demo automated for this one
• A discussion around the remaining caveats, particularly how we plan to store the Helm chart bundle in the catalog via OPM

Would be great to get a PTAL from or at least one of them @joelanford, @thetechnick, and @perdasilva before get this one merged.

Thank you 🙌

[camilamacedo86]

Hi @OchiengEd,

Just to clarify:

In the F2F, we talked about using a single internal type and converting everything to it. We also discussed having only one runtime—Buxcutter. PoC: #1946

Supporting Helm fully will take time, and it is a big journey as we have been discussing. There are still open questions and blockers. If we go with this approach (internal format), we probably want OPM/OLM to support the internal type first before anything else. I created an internal Slack channel so that we can discuss all details and caveats.

I’m OK merging this since it’s behind a feature gate—safe to experiment and doesn’t break anything. But it may change later.

PS: If we get it merged, it would be great to have a small doc with automated demo steps (as done for others feature gates), so people can understand what was done and iterate

Leaving final call to @joelanford, @thetechnick, and @perdasilva. 🔨

[tmshort]

@OchiengEd@itroyano
Regarding feature-gated APIs, you don't change any of the API files, so that makes things easier.
You need to create a kustomize component to enable this feature gate for experimental manifests/runs/testing.
For additional information:
https://github.com/operator-framework/operator-controller/blob/main/config/README.md
For an example:
https://github.com/operator-framework/operator-controller/tree/main/config/components/features/webhook-provider-certmanager
Once this is done, then your feature will be available in the make run-experimental target, and you can add e2e tests in to the test/experimental-e2e directory, which will be run via make test-experimental-e2e
https://github.com/operator-framework/operator-controller/tree/main/test/experimental-e2e

[OchiengEd]

@camilamacedo86@tmshort The documentation and feature-gated APIs concerns should be resolved. Kindly review and advice if anything else is needed at this time.

[tmshort]

There is a run-experimental make target that can be used to run this (of course it includes all other experimental features as well).
You might want to mention this alternative method.

[OchiengEd]

Good catch. Can we do a small revision after the PR is merged? I'm hesitant to add a change and kick out the one approval we have at this time.

[joelanford]

With the new run-experimental, I'm templated to say that our docs should only talk about the experimental feature set, and not get into the details of enabling/disabling individual features.

[tmshort]

The changes to the manifests look good!

[tmshort]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tmshort

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [tmshort]

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

[perdasilva]

/lgtm